MQTT-Topics für Messdaten planen: Einheit, Anlagenstruktur und Qualitätsstatus richtig abbilden

→ Produktkategorie: IIoT Lösungen

 

Ein Drucksensor sendet 6,42. Ein Energiezähler liefert 18450. Ein Temperaturmessumformer überträgt 72,3. Technisch sind alle drei Werte korrekt beim MQTT-Broker angekommen. Trotzdem fehlt eine entscheidende Information: Was bedeuten diese Zahlen?

Ohne eindeutige Messstellenbezeichnung, Einheit, Zeitstempel und Qualitätsstatus entstehen bereits bei kleinen IIoT-Projekten Interpretationsprobleme. Spätestens wenn mehrere Anlagen, Standorte und Hersteller angebunden werden, führen uneinheitliche MQTT-Topics zu komplizierten Auswertungen, fehlerhaften Alarmen und einem hohen Aufwand bei jeder Erweiterung.

Ein gutes MQTT-Datenmodell muss deshalb bereits vor der ersten produktiven Messstelle festgelegt werden. Dabei reicht es nicht aus, nur einen verständlichen Topic-Namen zu wählen. Topic-Hierarchie, Payload, Einheit, Datentyp, Zeitstempel, Qualitätsinformation, Retain-Verhalten, QoS und Statusmeldungen müssen zusammenpassen.

Geeignete Lösungen für die Anbindung von Feldgeräten, Edge-Gateways und MQTT-Infrastrukturen finden Sie unter IIoT Lösungen. Messgeräte und Komponenten für die Erfassung elektrischer und prozesstechnischer Messwerte sind unter Messgeräte für den Schaltschrankbau zusammengefasst.

Welche Aufgabe hat ein MQTT-Topic?

MQTT arbeitet nach dem Publish-Subscribe-Prinzip. Ein Publisher sendet eine Nachricht an ein Topic. Der MQTT-Broker verteilt diese Nachricht anschließend an alle Clients, die ein passendes Topic abonniert haben.

Ein Topic kann beispielsweise lauten:

plant01/line02/pump07/pressure

Das Topic beschreibt damit vor allem, wohin beziehungsweise zu welcher logischen Messstelle die Nachricht gehört.

Die eigentlichen Messdaten befinden sich in der Payload.

Beispiel:

{
  "value": 6.42,
  "unit": "bar",
  "timestamp": "2026-08-07T07:15:42.381Z",
  "quality": "good"
}

MQTT selbst schreibt nicht vor, wie industrielle Anlagen, Sensoren oder Messwerte innerhalb des Topic-Namens organisiert werden müssen. Diese Struktur muss daher projektspezifisch definiert oder über ein übergeordnetes Datenmodell wie Sparkplug standardisiert werden.

Genau diese Freiheit ist einer der Vorteile von MQTT, führt ohne klare Regeln jedoch schnell zu unterschiedlichen Strukturen innerhalb derselben Anlage.

Topic-Hierarchie nach Anlage und Messstelle aufbauen

Ein gutes Topic sollte die physische oder funktionale Anlagenstruktur nachvollziehbar abbilden.

Eine mögliche Struktur lautet:

site/{standort}/area/{bereich}/line/{linie}/device/{geraet}/telemetry/{messgroesse}

Ein konkretes Topic könnte damit beispielsweise lauten:

site/berlin/area/hall2/line/line03/device/pump07/telemetry/discharge_pressure

Die Hierarchie lässt sich lesen als:

• Standort: Berlin,
• Bereich: Halle 2,
• Linie: Linie 3,
• Gerät: Pumpe 7,
• Datenklasse: Telemetrie,
• Messgröße: Ausgangsdruck.

Diese Struktur ist besonders hilfreich, wenn später nicht nur ein einzelner Messwert, sondern mehrere hundert oder mehrere tausend Messstellen verwaltet werden.

Die Hierarchie sollte jedoch nicht unnötig tief werden. Eine Struktur mit zwölf oder fünfzehn Ebenen erschwert Administration, Wildcard-Abonnements und Fehlersuche.

Entscheidend ist, dass jede Ebene eine dauerhaft relevante organisatorische oder technische Bedeutung besitzt.

Stabile Namen und IDs verwenden

Topic-Namen sollten möglichst aus stabilen technischen Identitäten bestehen.

Ungünstig wäre beispielsweise:

halle_neben_lager/neue_pumpe/druck

Wird die Halle umbenannt oder die Pumpe ausgetauscht, verändert sich die gesamte Datenstruktur.

Besser sind stabile Bezeichnungen wie:

site01/area03/pump07/telemetry/pressure

Eine menschenlesbare Beschreibung kann zusätzlich als Metadatum gespeichert werden:

{
  "device_id": "pump07",
  "display_name": "Kühlwasserpumpe Werkzeugmaschine 4",
  "manufacturer": "Example",
  "location": "Halle 2 Nord"
}

Für die Namenskonvention sollten projektweit Regeln festgelegt werden. Empfehlenswert sind beispielsweise:

• nur Kleinbuchstaben verwenden,
• Leerzeichen vermeiden,
• Begriffe einheitlich in einer Sprache benennen,
• technische IDs nicht mit frei änderbaren Anzeigenamen vermischen,
• keine Seriennummer als alleinige Anlagenstruktur verwenden,
• keine wechselnden Prozesswerte in Topic-Namen aufnehmen.

MQTT-Topic-Namen sind außerdem case-sensitive. pump07 und Pump07 sind daher unterschiedliche Topics.

Messwerte, Status, Ereignisse und Befehle trennen

Eine der wichtigsten Entscheidungen besteht darin, unterschiedliche Informationsarten bereits im Topic eindeutig zu trennen.

Eine sinnvolle Struktur kann beispielsweise lauten:

site01/area03/pump07/telemetry/pressure
site01/area03/pump07/telemetry/temperature
site01/area03/pump07/status/availability
site01/area03/pump07/status/device
site01/area03/pump07/event/alarm
site01/area03/pump07/meta
site01/area03/pump07/cmd/setpoint
site01/area03/pump07/ack/setpoint

Damit lässt sich bereits anhand des Topics erkennen, ob eine Nachricht:

• einen Messwert enthält,
• den aktuellen Gerätestatus beschreibt,
• ein Ereignis meldet,
• Metadaten bereitstellt,
• einen Steuerbefehl enthält,
• eine Befehlsbestätigung darstellt.

Diese Trennung erleichtert außerdem die Vergabe von Zugriffsrechten. Ein Dashboard darf beispielsweise Telemetriedaten lesen, benötigt aber normalerweise keine Schreibberechtigung auf Command-Topics.

Welche Informationen gehören in die Payload?

Die Payload enthält den eigentlichen Inhalt der MQTT-Nachricht.

Für einen industriellen Messwert sollte mindestens geklärt sein:

• Messwert,
• Einheit,
• Zeitstempel,
• Qualitätsstatus.

Ein einfaches JSON-Beispiel:

{
  "value": 6.42,
  "unit": "bar",
  "timestamp": "2026-08-07T07:15:42.381Z",
  "quality": "good"
}

Bei Bedarf können zusätzliche Informationen ergänzt werden:

{
  "value": 6.42,
  "unit": "bar",
  "timestamp": "2026-08-07T07:15:42.381Z",
  "quality": "good",
  "sequence": 18422,
  "source": "PT204",
  "range_min": 0,
  "range_max": 10
}

Es ist jedoch nicht sinnvoll, bei jedem einzelnen Messwert umfangreiche unveränderliche Geräteinformationen mitzuschicken.

Hersteller, Gerätetyp, Messbereich, Firmware und Kalibrierdatum können beispielsweise separat als Metadaten veröffentlicht werden.

Einheiten eindeutig festlegen

Eine Zahl ohne Einheit ist kein eindeutig interpretierbarer Messwert.

Besonders problematisch wird dies bei Größen wie:

• Druck in bar, kPa, MPa oder psi,
• Temperatur in °C oder K,
• Durchfluss in l/min, m³/h oder Nm³/h,
• Energie in Wh, kWh oder MWh,
• Leistung in W oder kW.

Die Einheit sollte deshalb projektweit eindeutig definiert werden.

Ein verbreitetes Vorgehen besteht darin, die Einheit in der Payload beziehungsweise in den Metadaten zu speichern:

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

Eine Struktur wie:

pump07/pressure/bar

ist dagegen weniger flexibel. Wird die Datenhaltung später auf kPa vereinheitlicht, müsste sich gleichzeitig das Topic ändern.

Das ist ungünstig, weil bestehende Abonnements, Dashboards und Alarmregeln dadurch ebenfalls angepasst werden müssen.

Die Einheit gehört deshalb normalerweise zum Datenmodell und nicht zur Identität der Messstelle.

Zusätzlich sollte festgelegt werden, ob Werte bereits am Edge-Gateway in eine projektweit einheitliche Einheit konvertiert werden.

Das verhindert beispielsweise, dass:

• Sensor A Druck in bar liefert,
• Sensor B Druck in kPa liefert,
• Sensor C Druck in psi liefert

und die Umrechnung erst in jeder einzelnen Anwendung erneut durchgeführt werden muss.

Datentypen konsequent verwenden

Auch der Datentyp muss innerhalb des Datenmodells eindeutig sein.

Ein Messwert sollte beispielsweise nicht in einer Nachricht als Zahl und in der nächsten als Text übertragen werden.

Ungünstig:

{
  "value": "6.42"
}

Besser:

{
  "value": 6.42
}

Weitere typische Datentypen sind:

• Floating Point für analoge Messwerte,
• Integer für Zählerstände,
• Boolean für binäre Zustände,
• String für Status- oder Diagnoseinformationen.

Fehlende oder ungültige Messwerte sollten nicht einfach durch den Zahlenwert 0 ersetzt werden.

0 bar ist ein technisch gültiger Druckwert. Wird derselbe Wert gleichzeitig als Kennzeichnung für einen Kommunikationsfehler verwendet, kann die Auswertung nicht mehr zwischen beiden Zuständen unterscheiden.

Besser ist beispielsweise:

{
  "value": null,
  "unit": "bar",
  "quality": "bad",
  "reason": "sensor_timeout"
}

Zeitstempel richtig setzen

Ein Messwert ohne Zeitstempel beschreibt nur, welcher Wert irgendwann übertragen wurde.

Bei Echtzeit-Dashboards fällt dieser Unterschied zunächst kaum auf. Nach einem Netzwerkausfall oder einer Store-and-Forward-Übertragung wird er jedoch entscheidend.

Der Zeitstempel sollte möglichst dort erzeugt werden, wo der Messwert tatsächlich erfasst beziehungsweise eindeutig zeitlich zugeordnet wird.

Beispiel:

"timestamp": "2026-08-07T07:15:42.381Z"

Für verteilte Systeme empfiehlt sich eine einheitliche Zeitbasis, typischerweise UTC.

Zusätzlich kann das Zielsystem einen zweiten Zeitstempel erfassen:

• Source Timestamp: Zeitpunkt der Messwerterfassung,
• Server Timestamp: Zeitpunkt des Empfangs im Broker, Historian oder SCADA-System.

Diese Trennung ist besonders hilfreich bei:

• Mobilfunkverbindungen,
• temporären Netzwerkausfällen,
• Edge-Pufferung,
• Store-and-Forward,
• zeitkritischer Ereignisanalyse.

Edge-Gateway, SPS und Server sollten dafür über eine geeignete Zeitsynchronisation verfügen.

Qualitätsstatus für jeden Messwert berücksichtigen

Ein Messwert kann technisch übertragen worden sein und trotzdem für die Prozessbewertung ungültig sein.

Beispiele:

• Sensor befindet sich außerhalb seines Messbereichs,
• Modbus-Kommunikation zum Feldgerät ist ausgefallen,
• Messwert wurde während einer Wartung eingefroren,
• Sensor befindet sich im Fehlerzustand,
• Wert wurde manuell ersetzt,
• Zeitstempel ist nicht vertrauenswürdig.

Deshalb sollte der Qualitätsstatus nicht allein aus der Tatsache abgeleitet werden, dass eine MQTT-Nachricht angekommen ist.

Eine einfache Klassifizierung könnte lauten:

• good für gültige Messwerte,
• uncertain für eingeschränkt vertrauenswürdige Werte,
• bad für ungültige Werte.

Zusätzlich kann ein Grund übertragen werden:

{
  "value": null,
  "unit": "°C",
  "timestamp": "2026-08-07T07:15:42.381Z",
  "quality": "bad",
  "reason": "communication_timeout"
}

Weitere sinnvolle Statuscodes sind beispielsweise:

• sensor_fault,
• out_of_range,
• communication_timeout,
• substituted,
• manual_override,
• stale_data.

Damit kann ein Dashboard einen ungültigen Messwert anders darstellen als einen echten Prozesswert.

Messwertqualität und MQTT QoS nicht verwechseln

Der Qualitätsstatus eines Messwerts und die MQTT Quality of Service haben unterschiedliche Aufgaben.

Measurement Quality beschreibt, ob der Prozesswert technisch vertrauenswürdig ist.

MQTT QoS beschreibt dagegen die Zustellung einer MQTT-Nachricht zwischen Client und Broker.

MQTT QoS	Bedeutung	Typischer Einsatz
QoS 0	At most once	Hochfrequente Trends, bei denen einzelne verlorene Werte tolerierbar sind
QoS 1	At least once	Normale Messwerte, Statusinformationen und wichtige Meldungen
QoS 2	Exactly once	Spezielle Anwendungen, bei denen der zusätzliche Protokollaufwand gerechtfertigt ist

QoS 1 bedeutet deshalb nicht, dass der Messwert eine gute Qualität besitzt. Ein Sensorfehler kann mit QoS 1 vollkommen zuverlässig übertragen werden.

In der Praxis ist QoS 1 für viele industrielle Telemetrie- und Statusmeldungen ein sinnvoller Ausgangspunkt. Bei sehr hohen Datenraten kann QoS 0 für kontinuierliche Trends ausreichen.

QoS 2 sollte nur eingesetzt werden, wenn der konkrete Anwendungsfall die zusätzliche Kommunikationslast rechtfertigt.

Retained Messages sinnvoll einsetzen

Bei einer Retained Message speichert der MQTT-Broker die letzte als retained veröffentlichte Nachricht eines Topics. Ein neuer Subscriber erhält dadurch unmittelbar den zuletzt gespeicherten Zustand.

Das ist beispielsweise sinnvoll für:

• Gerätemetadaten,
• Konfigurationen,
• aktuellen Online- oder Offline-Status,
• aktuelle Betriebsart,
• bestimmte langsam veränderliche Zustände.

Retained Messages sind dagegen kein Ersatz für einen Historian.

Ein Event-Topic wie:

site01/area03/pump07/event/alarm

sollte normalerweise nicht einfach jede Alarmmeldung retained speichern. Ein neuer Subscriber könnte andernfalls ein längst vergangenes Ereignis wie einen aktuellen Alarm interpretieren.

Auch bei Messwerten muss bewusst entschieden werden.

Ein retained aktueller Messwert kann hilfreich sein, damit ein Dashboard unmittelbar einen letzten bekannten Zustand erhält. Die Payload muss dann jedoch unbedingt Zeitstempel und Qualitätsstatus enthalten, damit ein alter Wert nicht mit einem aktuellen Messwert verwechselt wird.

Für kontinuierliche Rohdatenströme ist Retain meist nicht erforderlich.

Birth und Last Will für den Gerätestatus nutzen

Ein IIoT-System sollte erkennen können, ob ein Gateway oder MQTT-Client tatsächlich verfügbar ist.

Dafür kann ein Status-Topic verwendet werden:

site01/area03/gateway01/status/availability

Beim erfolgreichen Verbindungsaufbau veröffentlicht das Gateway beispielsweise:

{
  "state": "online",
  "timestamp": "2026-08-07T07:10:00Z"
}

Zusätzlich wird beim MQTT-Verbindungsaufbau eine Last-Will-Nachricht registriert.

Bricht die Verbindung unerwartet ab, kann der Broker dadurch beispielsweise automatisch:

{
  "state": "offline"
}

publizieren.

Für den Status ist eine Retained Message sinnvoll, weil ein neu verbundenes SCADA- oder Dashboard-System unmittelbar erkennen kann, ob das Gateway zuletzt als online oder offline gemeldet wurde.

Eine vergleichbare und weiter standardisierte Zustandsverwaltung gehört zu den zentralen Funktionen von MQTT Sparkplug.

Messwerte und Befehle strikt trennen

MQTT kann nicht nur Messwerte verteilen, sondern auch Befehle übertragen. Gerade deshalb muss eine klare Trennung vorgesehen werden.

Messwert:

site01/area03/pump07/telemetry/speed

Befehl:

site01/area03/pump07/cmd/speed_setpoint

Bestätigung:

site01/area03/pump07/ack/speed_setpoint

Ein Command-Payload könnte beispielsweise enthalten:

{
  "value": 1450,
  "unit": "rpm",
  "request_id": "cmd-84721",
  "timestamp": "2026-08-07T07:20:12Z"
}

Die Bestätigung enthält dieselbe Request-ID:

{
  "request_id": "cmd-84721",
  "status": "accepted",
  "timestamp": "2026-08-07T07:20:12.120Z"
}

Damit kann eindeutig nachvollzogen werden, welcher Befehl verarbeitet wurde.

Momentane Befehle wie Start, Stop, Reset oder Ventil öffnen sollten normalerweise nicht retained veröffentlicht werden. Ein neu verbundenes Gerät könnte andernfalls einen alten Befehl erneut erhalten und ausführen.

Wenn eine Architektur bewusst mit einem retained Desired State arbeitet, muss dieses Verhalten explizit vorgesehen sein. Befehle müssen dann unter anderem idempotent, autorisiert, zeitlich begrenzt und eindeutig quittierbar sein.

Topic-Strukturen versionieren

Ein MQTT-Datenmodell entwickelt sich im Laufe eines Projekts weiter.

Deshalb sollte bereits zu Beginn definiert werden, wie inkompatible Änderungen behandelt werden.

Eine Möglichkeit ist eine Versionskennung im Namespace:

v1/site01/area03/pump07/telemetry/pressure

Bei einer grundlegenden Änderung kann parallel eine neue Struktur eingeführt werden:

v2/site01/area03/pump07/telemetry/pressure

Eine neue Version sollte jedoch nur bei tatsächlich inkompatiblen Änderungen eingeführt werden.

Ein Firmware-Update oder eine Änderung des Kalibrierdatums erfordert beispielsweise keine neue Topic-Version. Solche Informationen gehören in die Metadaten.

Vor jeder Änderung muss geprüft werden, welche Systeme das bestehende Topic verwenden:

• Dashboards,
• Historian,
• Alarmserver,
• Cloud-Dienste,
• MES,
• Analysesysteme,
• mobile Anwendungen.

Ein unkoordiniertes Umbenennen eines Topics kann alle diese Verbraucher gleichzeitig unterbrechen.

Ein Messwert pro Topic oder mehrere Werte pro Payload?

Für die Strukturierung gibt es grundsätzlich zwei verbreitete Ansätze.

Ein Messwert pro Topic

site01/pump07/telemetry/pressure
site01/pump07/telemetry/temperature
site01/pump07/telemetry/speed

Vorteile:

• sehr gezielte Subscriptions,
• einfache Zugriffssteuerung,
• einzelne Messgrößen können unabhängig publiziert werden,
• Retain kann je Messwert festgelegt werden.

Nachteile:

• größere Zahl von MQTT-Nachrichten,
• zusammengehörige Messwerte können unterschiedliche Zeitstempel besitzen,
• bei großen Geräten entstehen sehr viele Topics.

Mehrere Messwerte in einer Payload

Topic:

site01/pump07/telemetry

Payload:

{
  "timestamp": "2026-08-07T07:15:42.381Z",
  "pressure": {
    "value": 6.42,
    "unit": "bar",
    "quality": "good"
  },
  "temperature": {
    "value": 62.4,
    "unit": "°C",
    "quality": "good"
  },
  "speed": {
    "value": 1488,
    "unit": "rpm",
    "quality": "good"
  }
}

Vorteile:

• weniger einzelne MQTT-Nachrichten,
• zusammengehörige Werte können denselben Zeitstempel besitzen,
• kompakte Geräteabbildung.

Nachteile:

• Subscriber erhält immer die gesamte Payload,
• einzelne Messgrößen lassen sich über MQTT-Wildcards nicht separat abonnieren,
• Teiländerungen sind schwieriger zu behandeln.

Welche Variante besser ist, hängt von Datenrate, Anzahl der Messwerte und den Anforderungen der Verbraucher ab.

Entscheidend ist nicht, eine der beiden Varianten grundsätzlich als richtig zu betrachten, sondern sie projektweit konsistent einzusetzen.

Wildcards bereits beim Topic-Design berücksichtigen

Ein wesentlicher Vorteil von MQTT besteht darin, ganze Topic-Bereiche abonnieren zu können.

Mit dem Pluszeichen kann eine einzelne Ebene ersetzt werden.

Beispiel:

site01/area03/+/telemetry/pressure

Damit können beispielsweise Druckwerte unterschiedlicher Geräte innerhalb desselben Bereichs abonniert werden, sofern die Struktur entsprechend einheitlich aufgebaut ist.

Das Hash-Zeichen steht für mehrere nachfolgende Ebenen.

Beispiel:

site01/area03/#

Damit werden alle untergeordneten Topics des Bereichs erfasst.

Das funktioniert jedoch nur sinnvoll, wenn alle Geräte derselben Topic-Logik folgen.

Die Wildcards + und # gehören deshalb nicht in reguläre veröffentlichte Topic-Namen, sondern werden für Topic-Filter beziehungsweise Subscriptions verwendet.

Auch aus diesem Grund sollte die Struktur bereits vor dem Rollout mehrerer hundert Geräte getestet werden.

Wann ist Sparkplug sinnvoll?

Für kleinere MQTT-Anwendungen kann ein eigenes klar dokumentiertes Datenmodell vollkommen ausreichend sein.

Bei größeren industriellen Systemen stellt sich jedoch die Frage, ob ein standardisiertes Modell sinnvoller ist.

Eclipse Sparkplug definiert für industrielle MQTT-Architekturen unter anderem:

• einen standardisierten Topic Namespace,
• ein definiertes Payload-Modell,
• Geräte- und Messwertstrukturen,
• Session State Management,
• Birth- und Death-Mechanismen.

Dadurch können kompatible Systeme Geräte und Messgrößen wesentlich automatisierter erkennen.

Sparkplug ist besonders interessant bei:

• großen SCADA-Systemen,
• vielen Edge-Gateways,
• herstellerübergreifenden Anlagen,
• standardisierten Maschinenmodulen,
• mehreren MQTT-Verbrauchern,
• hohen Anforderungen an Zustandsinformation und Datenvalidität.

Wird Sparkplug eingesetzt, sollte dessen Namespace und Datenmodell konsequent umgesetzt werden. Ein halb eigenes und halb Sparkplug-basiertes Schema verliert einen wesentlichen Teil der gewünschten Interoperabilität.

Berechtigungen und Sicherheit im Topic-Modell berücksichtigen

Das Topic-Design beeinflusst unmittelbar, wie einfach Zugriffsrechte konfiguriert werden können.

Ein Dashboard benötigt beispielsweise nur Leserechte auf:

site01/+/+/telemetry/#

Eine Wartungsanwendung kann zusätzlich Status- und Diagnoseinformationen lesen.

Schreibrechte auf:

site01/+/+/cmd/#

sollten dagegen ausschließlich ausdrücklich autorisierten Clients gewährt werden.

Bereits bei der Architektur sollten daher berücksichtigt werden:

• TLS beziehungsweise MQTTS,
• eindeutige Client-Identitäten,
• gerätespezifische Zertifikate,
• rollenbasierte Zugriffsrechte,
• Topic-basierte ACLs,
• Trennung von Telemetrie und Steuerung,
• Protokollierung administrativer Änderungen,
• Zertifikats- und Schlüsselmanagement.

Ein schlecht strukturiertes Topic-Modell führt häufig zu sehr großzügigen Berechtigungen wie:

site01/#

für Clients, die tatsächlich nur drei Messwerte lesen müssten.

Ein gutes Datenmodell verbessert deshalb nicht nur die Übersichtlichkeit, sondern auch die Sicherheit.

Empfohlener Planungsablauf

1. Anlagenhierarchie definieren: Standort, Bereich, Linie, Maschine und Gerät eindeutig strukturieren.
2. Stabile IDs festlegen: Keine frei änderbaren Anzeigenamen als primäre Identität verwenden.
3. Datenklassen trennen: Telemetry, Status, Event, Meta, Command und Acknowledgement definieren.
4. Messgrößen vereinheitlichen: Einheit, Bezeichnung und Datentyp für jede Größe festlegen.
5. Zeitmodell festlegen: Source Timestamp, UTC und Zeitsynchronisation definieren.
6. Quality Codes definieren: Mindestens Good, Uncertain und Bad sowie wichtige Detailgründe festlegen.
7. Payload-Schema festlegen: Einzelwerte oder gruppierte Payloads bewusst auswählen.
8. QoS definieren: Kommunikationsanforderung je Datenklasse bestimmen.
9. Retain-Regeln festlegen: Status und Metadaten von Ereignissen und Historienwerten unterscheiden.
10. Availability definieren: Online-, Offline- und Last-Will-Verhalten festlegen.
11. Command-Struktur definieren: Messwerte und Steuerbefehle technisch und hinsichtlich der Berechtigungen trennen.
12. Wildcard-Abfragen testen: Typische SCADA- und Historian-Subscriptions simulieren.
13. ACL-Konzept erstellen: Lese- und Schreibrechte pro Topic-Bereich definieren.
14. Versionierung festlegen: Vorgehen bei inkompatiblen Datenmodelländerungen dokumentieren.
15. Pilot aufbauen: Struktur zunächst mit einigen repräsentativen Messstellen testen.
16. Erst anschließend skalieren: Topic-Template automatisiert auf weitere Geräte ausrollen.

Praxisbeispiel für eine Produktionsanlage

Eine Produktionslinie besitzt mehrere Pumpen, einen Wärmetauscher und einen elektrischen Hauptabgang.

Folgende Messwerte sollen über MQTT bereitgestellt werden:

• Druck hinter Pumpe 7,
• Temperatur hinter dem Wärmetauscher,
• elektrische Wirkleistung des Linienabgangs.

Zunächst werden folgende Topics festgelegt:

site/berlin/area/hall2/line/line03/device/pump07/telemetry/discharge_pressure
site/berlin/area/hall2/line/line03/device/hx01/telemetry/outlet_temperature
site/berlin/area/hall2/line/line03/device/em01/telemetry/active_power

Der Druckwert wird beispielsweise übertragen als:

{
  "value": 6.42,
  "unit": "bar",
  "timestamp": "2026-08-07T07:15:42.381Z",
  "quality": "good"
}

Die Temperatur:

{
  "value": 72.3,
  "unit": "°C",
  "timestamp": "2026-08-07T07:15:42.381Z",
  "quality": "good"
}

Die Leistung:

{
  "value": 84.7,
  "unit": "kW",
  "timestamp": "2026-08-07T07:15:42.381Z",
  "quality": "good"
}

Zusätzlich erhält jedes Gerät ein Status-Topic:

site/berlin/area/hall2/line/line03/device/pump07/status/availability
site/berlin/area/hall2/line/line03/device/hx01/status/availability
site/berlin/area/hall2/line/line03/device/em01/status/availability

Für diese Statusinformationen werden retained Online- beziehungsweise Offline-Meldungen verwendet.

Nach einem Kommunikationsausfall des Drucksensors publiziert das Edge-Gateway nicht einfach den letzten Messwert als aktuellen Wert weiter. Stattdessen wird der Qualitätsstatus angepasst:

{
  "value": null,
  "unit": "bar",
  "timestamp": "2026-08-07T07:18:05.112Z",
  "quality": "bad",
  "reason": "communication_timeout"
}

Dadurch kann das SCADA-System eindeutig zwischen einem tatsächlichen Prozessdruck von 0 bar und einem ausgefallenen Sensor unterscheiden.

Später wird eine zweite Produktionshalle angebunden. Da dieselbe Topic-Struktur verwendet wird, müssen weder Historian noch Dashboard grundsätzlich neu programmiert werden. Sie abonnieren lediglich einen zusätzlichen Standortbereich.

Genau darin liegt der große Vorteil eines frühzeitig geplanten MQTT-Datenmodells.

Typische Fehler beim MQTT Topic Design

Fehler	Mögliche Folge	Geeignete Maßnahme
Freie Topic-Namen für jedes Gerät	Keine einheitlichen Wildcard-Abfragen möglich	Verbindliche Topic-Schablone definieren
Einheit nur implizit bekannt	Werte werden falsch interpretiert	Einheit eindeutig im Datenmodell speichern
Einheit im Topic fest eingebaut	Einheitenänderung verändert die Topic-Adresse	Einheit in Payload oder Metadaten abbilden
Zahl teilweise als String übertragen	Historian und Analyse benötigen Sonderbehandlung	Datentypen verbindlich definieren
Kein Zeitstempel vorhanden	Gepufferte Daten werden zeitlich falsch eingeordnet	Source Timestamp übertragen
Kein Qualitätsstatus	Fehlerwerte erscheinen als gültige Prozesswerte	Quality Code für Messwerte vorsehen
0 als Ersatz für Kommunikationsfehler	Echter Nullwert und Fehler sind nicht unterscheidbar	Nullwert beziehungsweise ungültigen Wert mit Bad Quality übertragen
MQTT QoS mit Messwertqualität verwechselt	Transportqualität wird fälschlich als Sensorqualität bewertet	QoS und Measurement Quality getrennt modellieren
Alle Nachrichten retained	Alte Ereignisse erscheinen neuen Clients als aktueller Zustand	Retain nur gezielt für Zustandsinformationen verwenden
Start- oder Reset-Befehl retained	Alter Befehl kann nach Wiederverbindung erneut verarbeitet werden	Momentane Commands normalerweise nicht retained übertragen
Messwerte und Befehle im selben Namespace	Schwierige ACL-Konfiguration und erhöhtes Fehlbedienungsrisiko	Telemetry und Command strikt trennen
Gerätename statt stabiler ID verwendet	Umbenennung verändert Historie und Subscriptions	Stabile technische IDs verwenden
Topic-Struktur erst nach Rollout definiert	Hoher Migrationsaufwand	Datenmodell bereits im Pilotprojekt festlegen

Was gehört in die Topic-Dokumentation?

Ein produktives MQTT-System sollte nicht nur technisch funktionieren, sondern vollständig dokumentiert sein.

Die Dokumentation sollte mindestens enthalten:

• verwendete MQTT-Version,
• Broker beziehungsweise Broker-Cluster,
• Topic-Namenskonvention,
• Bedeutung jeder Hierarchieebene,
• Liste zulässiger Geräte- und Messgrößenbezeichnungen,
• Payload-Schema,
• Datentyp jeder Messgröße,
• verwendete Einheit,
• Zeitstempelformat,
• Quality Codes und deren Bedeutung,
• QoS je Datenklasse,
• Retain-Verhalten je Datenklasse,
• Birth- und Last-Will-Konzept,
• Command- und Acknowledgement-Struktur,
• Wildcard-Beispiele,
• Zugriffsrechte und ACLs,
• Version des Datenmodells,
• Änderungshistorie.

Zusätzlich empfiehlt sich eine zentrale Messstellenliste.

Messstelle	Topic	Datentyp	Einheit	Intervall
PT204	…/pump07/telemetry/discharge_pressure	Float	bar	2 s
TT301	…/hx01/telemetry/outlet_temperature	Float	°C	5 s
EM01	…/em01/telemetry/active_power	Float	kW	2 s

Damit können SPS-Programmierer, IIoT-Integratoren, SCADA-Entwickler und Betreiber dieselben Definitionen verwenden.

Welche Produkte und Lösungen eignen sich?

ICS IIoT Lösungen

Die ICS IIoT Lösungen verbinden Feldgeräte, Sensoren und Steuerungen mit Edge-Gateways sowie übergeordneten IT- und OT-Systemen.

Typische Feldschnittstellen sind unter anderem:

• RS-485 und Modbus RTU,
• HART,
• IO-Link,
• OPC UA,
• Ethernet.

Das Edge-Gateway kann Messwerte zusammenführen, skalieren, mit Zeitstempeln und Statusinformationen versehen und anschließend über MQTT beziehungsweise HTTPS bereitstellen.

Dadurch können auch bestehende Feldgeräte ohne eigene MQTT-Schnittstelle in ein einheitliches Topic- und Datenmodell integriert werden.

IDS350 Drucksensor mit IO-Link

Der IDS350 ist ein elektronischer Drucksensor mit IO-Link-Schnittstelle.

Neben Prozessdaten können über IO-Link Diagnose- und Statusinformationen bereitgestellt werden. Damit eignet sich der Sensor gut als Beispiel für ein Feldgerät, dessen Informationen über einen IO-Link-Master beziehungsweise ein Edge-Gateway auf ein einheitliches MQTT-Datenmodell abgebildet werden.

So können beispielsweise unterschiedliche Informationstypen getrennt publiziert werden:

.../ids350/telemetry/pressure
.../ids350/status/device
.../ids350/event/alarm
.../ids350/meta

Messgeräte für den Schaltschrankbau

Über die Kategorie Messgeräte für den Schaltschrankbau lassen sich unter anderem elektrische Messwerte, Energiegrößen, Temperaturen und weitere Prozesssignale erfassen.

Geräte mit digitalen Schnittstellen wie RS-485 beziehungsweise Modbus können über ein Edge-Gateway in MQTT-Infrastrukturen integriert werden.

Damit lassen sich auch Brownfield-Anlagen nach einem einheitlichen Modell abbilden, obwohl die eigentlichen Feldgeräte MQTT nicht direkt unterstützen.

Edge-Gateway und Datenmodellierung

Das Edge-Gateway besitzt in einer solchen Architektur eine zentrale Funktion.

Es übernimmt beispielsweise:

• Register-Mapping,
• Skalierung,
• Einheitenumrechnung,
• Zeitstempelung,
• Quality Mapping,
• lokale Plausibilitätsprüfung,
• Alarmvorverarbeitung,
• Store-and-Forward,
• MQTT-Publishing.

Dadurch muss die Cloud nicht wissen, ob ein Druckwert ursprünglich über 4 bis 20 mA, HART, Modbus oder IO-Link erfasst wurde.

Für die übergeordnete Anwendung bleibt die Datenstruktur identisch.

ICS Schneider Messtechnik unterstützt bei Feldgeräteauswahl, Schnittstellenkonzept, Register-Mapping, MQTT Topic Design, Datenmodell, Edge-Konfiguration und Inbetriebnahme kompletter IIoT-Messlösungen.

Fazit

Ein gutes MQTT-System beginnt nicht beim Broker, sondern beim Datenmodell.

Die Topic-Hierarchie sollte Standort, Anlagenbereich, Gerät und Datenklasse eindeutig und dauerhaft abbilden. Stabile technische IDs sind dabei besser geeignet als frei änderbare Anzeigenamen.

Messwerte benötigen neben dem eigentlichen Zahlenwert mindestens eine eindeutig definierte Einheit, einen Zeitstempel und einen Qualitätsstatus. Ungültige Werte dürfen nicht einfach durch 0 ersetzt werden.

MQTT QoS und Messwertqualität sind vollständig unterschiedliche Informationen. QoS beschreibt die Nachrichtenzustellung, während der Quality Code die Verwendbarkeit des Prozesswerts beschreibt.

Retained Messages eignen sich besonders für Metadaten und aktuelle Zustände. Sie ersetzen jedoch keinen Historian und sollten für Ereignisse oder einmalige Befehle nur verwendet werden, wenn dies ausdrücklich Teil des Systemkonzepts ist.

Messwerte, Statusinformationen, Ereignisse und Steuerbefehle sollten getrennte Topic-Bereiche besitzen. Dadurch werden Auswertung, Wildcard-Abonnements und Sicherheitsregeln wesentlich einfacher.

Bei größeren industriellen Installationen kann Eclipse Sparkplug sinnvoll sein, weil Topic Namespace, Payload und Zustandsverwaltung bereits standardisiert sind.

Am wichtigsten ist jedoch die Konsistenz. Eine einfache, vollständig dokumentierte Topic-Struktur ist langfristig wertvoller als ein komplexes Datenmodell, das von jedem Gateway unterschiedlich umgesetzt wird.

Häufige Fragen zum MQTT Topic Design

Soll die Einheit im MQTT-Topic stehen?

In der Regel besser nicht. Die Einheit gehört zum Datenmodell beziehungsweise zur Payload oder zu den Metadaten. Dadurch kann die Einheit geändert oder zentral standardisiert werden, ohne dass sich die Topic-Adresse ändert.

Soll jeder Messwert ein eigenes Topic bekommen?

Das hängt von der Anwendung ab. Einzelne Topics ermöglichen sehr gezielte Subscriptions. Eine gemeinsame Payload reduziert dagegen die Zahl der Nachrichten und kann zusammengehörige Messwerte mit demselben Zeitstempel übertragen.

Welche Informationen sollte ein Messwert mindestens enthalten?

Für industrielle Anwendungen sind Messwert, Einheit, Zeitstempel und Qualitätsstatus eine sinnvolle Grundstruktur.

Was ist ein Quality Code?

Er beschreibt, ob ein Messwert gültig und vertrauenswürdig ist. Eine einfache Einteilung besteht beispielsweise aus Good, Uncertain und Bad mit zusätzlichen Detailgründen.

Ist MQTT QoS dasselbe wie die Qualität des Messwerts?

Nein. MQTT QoS beschreibt die Zustellung der Nachricht. Der Quality Code beschreibt dagegen die technische Qualität des Messwerts.

Welches QoS sollte für Messwerte verwendet werden?

QoS 1 ist für viele industrielle Messwerte und Statusmeldungen ein sinnvoller Ausgangspunkt. Für hochfrequente Trends kann QoS 0 genügen. QoS 2 sollte nur verwendet werden, wenn dessen zusätzlicher Protokollaufwand tatsächlich erforderlich ist.

Sollte der letzte Messwert retained werden?

Das kann für aktuelle Zustandswerte sinnvoll sein. Der Messwert muss dann aber einen Zeitstempel und Qualitätsstatus enthalten, damit ein neuer Subscriber einen alten retained Wert nicht für einen aktuellen Wert hält.

Sollten Alarme retained werden?

Ereignisorientierte Alarmmeldungen normalerweise nicht. Für einen aktuellen Alarmzustand kann dagegen ein separates State-Topic retained geführt werden.

Darf ein Start- oder Stop-Befehl retained werden?

Momentane Steuerbefehle sollten normalerweise nicht retained sein, da ein später neu verbundenes Gerät den gespeicherten Befehl erneut erhalten könnte.

Warum ist ein Last Will sinnvoll?

Damit kann der Broker bei einem unerwarteten Verbindungsabbruch automatisch den Offline-Zustand eines Gateways oder Geräts veröffentlichen.

Wann sollte Sparkplug verwendet werden?

Sparkplug ist besonders interessant für größere industrielle MQTT- und SCADA-Architekturen, in denen ein standardisierter Topic Namespace, ein definiertes Payload-Modell und einheitliches Session State Management benötigt werden.

Warum sollte ein Topic nicht den frei vergebenen Gerätenamen enthalten?

Ein Anzeigename kann sich im Anlagenleben ändern. Eine stabile Geräte-ID bleibt dagegen erhalten und verhindert, dass Historie, Dashboards und Abonnements nach einer Umbenennung angepasst werden müssen.