Modbus-Sensoren ins IIoT bringen: Register-Mapping, Skalierung und Einheiten sauber dokumentieren

→ Produktkategorie: IIoT Lösungen

 

Modbus-Sensoren lassen sich vergleichsweise einfach an eine SPS, einen Datenlogger oder ein Edge-Gateway anbinden. Eine erfolgreiche Kommunikation bedeutet jedoch noch nicht, dass der übertragene Messwert fachlich richtig interpretiert wird.

Das Gateway kann beispielsweise ein Register zuverlässig auslesen und trotzdem einen vollkommen unplausiblen Wert an die Cloud übertragen. Häufige Ursachen sind eine um eins verschobene Registeradresse, ein falsch gewählter Datentyp, eine vertauschte Word-Reihenfolge oder ein nicht berücksichtigter Skalierungsfaktor.

Zusätzliche Fehler entstehen, wenn nur der Zahlenwert übernommen wird. Ohne Einheit, Zeitstempel, Qualitätsstatus, gültigen Wertebereich und eindeutige Gerätezuordnung lässt sich später kaum beurteilen, ob ein Messwert tatsächlich korrekt, veraltet oder durch eine Kommunikationsstörung entstanden ist.

Geeignete Gateways, Integrationsleistungen und Lösungen für die Verbindung von Feldgeräten mit IT- und Cloud-Systemen finden Sie im Bereich IIoT-Lösungen. Module zur Erfassung und Ausgabe analoger oder digitaler Signale über Modbus sind in der Kategorie Modbus I/O zusammengefasst.

Vom Sensorregister bis zum IIoT-Messwert

Zwischen dem physikalischen Messwert und der Anzeige im Dashboard liegen mehrere Verarbeitungsschritte:

1. Der Sensor erfasst die physikalische Messgröße.
2. Die interne Elektronik wandelt den Wert in einen digitalen Zahlenwert um.
3. Der Wert wird in einem oder mehreren Modbus-Registern abgelegt.
4. Ein Modbus-Client liest die Register aus.
5. Das Gateway interpretiert Datentyp, Reihenfolge und Skalierung.
6. Der technische Wert wird einer Einheit und Messstellen-ID zugeordnet.
7. Das Gateway ergänzt Zeitstempel und Qualitätsstatus.
8. Der Datensatz wird beispielsweise per MQTT oder HTTPS übertragen.
9. Dashboard, Datenbank oder Analysesoftware verarbeitet den Wert weiter.

Ein Fehler in einem einzigen dieser Schritte kann dazu führen, dass ein plausibel aussehender, aber fachlich falscher Wert gespeichert wird. Besonders kritisch sind Fehler, die keine Kommunikationsstörung auslösen. Ein um den Faktor zehn falsch skalierter Messwert kann über Monate aufgezeichnet werden, ohne dass das System einen technischen Fehler meldet.

Das Mapping sollte deshalb nicht nur den Transport beschreiben. Es muss die vollständige Bedeutung des Messwerts vom Rohregister bis zur Zielvariable festlegen.

Modbus RTU und Modbus TCP unterscheiden

Modbus RTU

Modbus RTU wird typischerweise über eine serielle RS-485-Verbindung übertragen. Mehrere Geräte können an einem gemeinsamen Bus betrieben werden. Jedes Gerät benötigt eine eindeutige Teilnehmeradresse.

Für eine funktionierende Verbindung müssen Client und Sensor dieselben Kommunikationsparameter verwenden:

• Teilnehmeradresse,
• Baudrate,
• Anzahl der Datenbits,
• Parität,
• Anzahl der Stoppbits,
• Timeout und Wiederholversuche.

Zusätzlich müssen Busstruktur, Abschlusswiderstände, Schirmung und Bezugspotenzial zur RS-485-Installation passen. Eine sternförmige Verdrahtung oder lange Stichleitungen können zu sporadischen Kommunikationsfehlern führen.

Modbus TCP

Modbus TCP überträgt Modbus-Telegramme über Ethernet und TCP/IP. Statt Baudrate und Parität werden insbesondere IP-Adresse, Subnetz, Port und gegebenenfalls Unit Identifier benötigt.

Der Unit Identifier kann relevant sein, wenn ein Modbus-TCP-Gateway auf nachgeschaltete Modbus-RTU-Geräte zugreift. Er darf deshalb nicht grundsätzlich ignoriert werden.

Modbus TCP sollte nicht direkt aus einem Produktionsnetz in das öffentliche Internet weitergeleitet werden. Für die IIoT-Anbindung wird ein kontrolliertes Edge-Gateway eingesetzt, das die OT-Kommunikation von der verschlüsselten Verbindung zu IT- oder Cloud-Systemen trennt.

Geräteadresse und Kommunikationsparameter dokumentieren

Die Dokumentation sollte jedes Modbus-Gerät eindeutig einer realen Messstelle zuordnen. Eine reine Liste mit Teilnehmeradressen reicht nicht aus.

Sinnvolle Angaben sind:

• Anlagen- und Messstellenbezeichnung,
• Hersteller und Gerätetyp,
• Seriennummer oder Asset-ID,
• Modbus RTU oder Modbus TCP,
• Teilnehmeradresse beziehungsweise IP-Adresse,
• serielle Parameter oder TCP-Port,
• Firmwarestand,
• Version des verwendeten Modbus-Handbuchs,
• Position im Schaltschrank oder in der Anlage.

Wird ein Sensor ersetzt und besitzt das neue Gerät einen anderen Firmwarestand, kann sich das Registermodell ändern. Deshalb sollten Firmware und Dokumentationsversion Bestandteil der Mapping-Freigabe sein.

Registertyp und Registeradresse richtig zuordnen

Modbus unterscheidet vier grundlegende Datenbereiche:

Datenbereich	Typische Funktion	Zugriff
Coils	Binäre Schaltwerte	Lesen und Schreiben
Discrete Inputs	Binäre Zustände oder Eingänge	Nur Lesen
Input Registers	Mess- und Eingangswerte als 16-Bit-Wörter	Nur Lesen
Holding Registers	Messwerte, Parameter oder Sollwerte	Lesen, teilweise Schreiben

Ein Wert in einem Input Register kann nicht automatisch mit derselben Abfrage gelesen werden wie ein Holding Register. Der Registertyp beziehungsweise der daraus resultierende Funktionscode gehört daher zwingend in die Mapping-Tabelle.

0-basierte und 1-basierte Adressierung

Eine häufige Fehlerquelle ist die unterschiedliche Darstellung von Registeradressen. Ein Gerätehandbuch kann beispielsweise das Holding Register 40021 nennen, während eine Gateway-Software den zugehörigen nullbasierten Offset 20 erwartet.

Andere Programme erwarten direkt 40021 oder 21. Es gibt deshalb keine sichere Möglichkeit, die Eingabeform allein aus der angezeigten Zahl abzuleiten.

Für jedes Projekt sollte dokumentiert werden:

• Adresse aus dem Gerätehandbuch,
• Registertyp,
• nullbasierter Protokolloffset,
• tatsächlich im Gateway eingetragener Wert.

Ein erfolgreicher Lesezugriff beweist nicht, dass die richtige Adresse verwendet wird. Auch ein benachbartes Register kann einen gültigen Zahlenwert enthalten.

Datentyp, Registerlänge und Vorzeichen beachten

Ein einzelnes Modbus-Register enthält ein 16-Bit-Wort. Ein technischer Messwert kann jedoch aus einem oder mehreren Registern bestehen.

Typische Datentypen sind:

• UINT16: vorzeichenlose Ganzzahl in einem Register,
• INT16: vorzeichenbehaftete Ganzzahl in einem Register,
• UINT32: vorzeichenlose Ganzzahl in zwei Registern,
• INT32: vorzeichenbehaftete Ganzzahl in zwei Registern,
• FLOAT32: Gleitkommazahl in zwei Registern,
• FLOAT64: Gleitkommazahl in vier Registern,
• Bitfeld: mehrere Statusinformationen innerhalb eines Registers.

Wird ein negativer INT16-Wert als UINT16 interpretiert, entsteht ein großer positiver Zahlenwert. Aus −10 kann dann beispielsweise 65526 werden.

Bei Werten über mehrere Register muss zusätzlich die korrekte Startadresse und Registeranzahl eingestellt werden. Ein FLOAT32-Wert darf nicht als zwei unabhängige 16-Bit-Werte verarbeitet werden.

Byte- und Word-Reihenfolge richtig einstellen

Bei mehrteiligen Werten muss das Gateway wissen, in welcher Reihenfolge die Bytes und Register zusammengesetzt werden. Besonders bei 32-Bit-Gleitkommazahlen treten unterschiedliche Varianten auf.

Für vier Bytes A, B, C und D sind unter anderem folgende Darstellungen möglich:

• ABCD,
• BADC,
• CDAB,
• DCBA.

Hersteller und Software verwenden dafür Bezeichnungen wie Big Endian, Little Endian, Byte Swap, Word Swap oder Mixed Endian. Diese Begriffe werden nicht in jeder Software identisch verwendet.

Die sicherste Methode ist ein Vergleich mit einem bekannten Referenzwert:

1. Aktuellen Messwert am Gerätedisplay oder über eine Hersteller-Software ablesen.
2. Die beiden Rohregister in hexadezimaler Darstellung erfassen.
3. Alle unterstützten Byte- und Word-Reihenfolgen prüfen.
4. Nur die Variante übernehmen, die den bekannten Wert korrekt ergibt.

Die getestete Reihenfolge sollte als konkrete Bytefolge dokumentiert werden und nicht nur als möglicherweise missverständliche Bezeichnung wie „Little Endian“.

Skalierungsfaktor, Offset und Einheit übernehmen

Viele Geräte übertragen keine fertige Gleitkommazahl, sondern einen skalierten Ganzzahlwert. Ein Rohwert von 253 kann beispielsweise 25,3 °C bedeuten.

Eine allgemeine Umrechnung lautet:

Technischer Wert = Rohwert × Faktor + Offset

Beispiele:

Rohwert	Faktor	Offset	Ergebnis
253	0,1	0	25,3 °C
1250	0,01	0	12,50 bar
500	0,1	−50	0,0 %

Die Einheit darf nicht allein aus dem Namen des Sensors abgeleitet werden. Ein Drucksensor kann je nach Parametrierung bar, mbar, kPa oder MPa übertragen. Ein Temperaturwert kann in °C, K oder einem herstellerspezifisch skalierten Rohformat vorliegen.

Im IIoT-Datenmodell sollten mindestens gespeichert werden:

• technischer Wert,
• Einheit,
• Rohwert oder Rohregister für Diagnosezwecke,
• verwendeter Faktor und Offset,
• gültiger Wertebereich.

Eine Änderung der Geräteeinheit darf nicht unbemerkt zu einer anderen Bedeutung der übertragenen Zahl führen. Parameteränderungen am Sensor müssen deshalb mit der Gateway-Konfiguration abgeglichen werden.

Qualitätsstatus und Fehlerwerte abbilden

Ein übertragener Zahlenwert ist nur dann brauchbar, wenn gleichzeitig bekannt ist, ob er gültig ist. Der Qualitätsstatus sollte nicht aus dem Wertebereich allein abgeleitet werden.

Mögliche Qualitätszustände sind:

• Good: Kommunikation und Gerätestatus sind fehlerfrei.
• Uncertain: Wert ist vorhanden, aber beispielsweise außerhalb des kalibrierten Bereichs.
• Bad: Sensor meldet einen internen Fehler.
• Communication Error: Gerät antwortet nicht oder Telegramm ist ungültig.
• Stale: letzter bekannter Wert ist älter als die zulässige Aktualisierungszeit.
• Maintenance: Gerät befindet sich im Wartungs- oder Simulationszustand.

Viele Sensoren besitzen separate Statusregister oder Bitfelder. Ein Bit kann beispielsweise Sensorbruch, Überlast, Parametrierfehler oder Wartungsbedarf melden. Diese Informationen sollten nicht verworfen werden.

Zusätzlich können bestimmte Rohwerte als Fehlerkennzeichen reserviert sein, beispielsweise:

• maximaler Registerwert,
• minimaler negativer Zahlenwert,
• NaN bei Gleitkommazahlen,
• herstellerspezifischer Ersatzwert.

Solche Werte dürfen nicht als realer Prozesswert in die Datenbank gelangen. Die genaue Bedeutung genaue Bedeutung muss dem jeweiligen Gerätehandbuch entnommen werden.

Zeitstempel und Abfrageintervall festlegen

Ein IIoT-Messwert benötigt einen nachvollziehbaren Zeitbezug. Dabei sind verschiedene Zeitpunkte zu unterscheiden:

• Zeitpunkt der Messung im Sensor,
• Zeitpunkt der Modbus-Abfrage durch das Gateway,
• Zeitpunkt der Übertragung,
• Zeitpunkt des Eingangs in der Cloud oder Datenbank.

Besitzt der Sensor keinen eigenen Zeitstempel, sollte das Gateway den Zeitpunkt der erfolgreichen Abfrage verwenden. Die Uhr des Gateways muss dafür zuverlässig synchronisiert sein.

Das Modbus-Abfrageintervall und das Übertragungsintervall müssen nicht identisch sein. Ein Gateway kann beispielsweise jede Sekunde abfragen, aber nur alle 30 Sekunden Mittelwert, Minimum und Maximum übertragen.

Bei der Festlegung sind zu berücksichtigen:

• Dynamik der Messgröße,
• Ansprechzeit des Sensors,
• Anzahl der Geräte am Bus,
• Baudrate und Telegrammlänge,
• Cloud- und Mobilfunkkosten,
• erforderliche Alarmreaktionszeit,
• lokale Pufferung bei Verbindungsunterbrechungen.

Eine sehr schnelle Abfrage verbessert den Messwert nicht, wenn der Sensor intern nur alle zehn Sekunden aktualisiert wird.

Mapping im Edge-Gateway aufbauen

Das Edge-Gateway sollte nicht lediglich Rohregister weiterleiten. Es bildet die Modbus-Daten auf ein einheitliches, herstellerunabhängiges Datenmodell ab.

Ein sinnvoller Datensatz kann enthalten:

{
  "asset_id": "waterplant-pump02-pressure01",
  "value": 12.48,
  "unit": "bar",
  "timestamp": "2026-08-04T07:15:30Z",
  "quality": "good",
  "source": "modbus-rtu",
  "slave_id": 7
}

Der Payload muss nicht bei jeder Anlage genau so aussehen. Entscheidend ist, dass dieselbe Bedeutung systemweit gleich dargestellt wird.

Das Gateway übernimmt typischerweise:

• Modbus-Abfrage,
• Zusammenfügen mehrerer Register,
• Datentyp- und Endian-Konvertierung,
• Skalierung und Einheit,
• Grenz- und Plausibilitätsprüfung,
• Qualitätsstatus,
• Zeitstempel,
• lokale Datenpufferung,
• Übertragung per MQTT, HTTPS oder OPC UA.

Modbus-Kommunikation und Cloud-Verbindung sollten klar getrennt sein. Das Gateway kommuniziert lokal mit den Feldgeräten und stellt nach außen nur die benötigten, abgesicherten Dienste bereit.

Welche Angaben gehören in eine Mapping-Tabelle?

Eine vollständige Mapping-Tabelle sollte mindestens folgende Spalten enthalten:

Feld	Beispiel
Asset-ID	pump02-pressure01
Gerät / Firmware	Drucksensor, Firmware 2.4
Schnittstelle	Modbus RTU
Teilnehmeradresse	7
Registertyp	Holding Register
Handbuchadresse	40021
Gateway-Offset	20
Registeranzahl	2
Datentyp	FLOAT32
Byte-/Word-Reihenfolge	CDAB
Faktor / Offset	1 / 0
Einheit	bar
Gültiger Bereich	0 bis 25 bar
Statusregister	30005, Bit 2 = Sensorfehler
Abfrageintervall	1 s
Zielvariable / Topic	plant/pump02/pressure
Prüfstatus	Geprüft am 04.08.2026

Zusätzlich sollte die Tabelle einen Verantwortlichen, einen Versionsstand und eine Änderungshistorie besitzen. Eine Mapping-Datei ohne Versionsverwaltung wird bei späteren Umbauten schnell unzuverlässig.

Mapping mit Referenzwerten prüfen

Die Inbetriebnahme sollte nicht ausschließlich anhand der Kommunikation erfolgen. Jeder wichtige Messwert muss mit einem bekannten Referenzzustand verglichen werden.

Ein sinnvoller Test umfasst:

1. Wert am Gerätedisplay oder in der Hersteller-Software ablesen.
2. Rohregister mit einem unabhängigen Modbus-Testprogramm erfassen.
3. Datentyp und Registerreihenfolge manuell kontrollieren.
4. Skalierung und Einheit prüfen.
5. Wert am Gateway vergleichen.
6. Übertragenen Wert im Dashboard oder Zielsystem kontrollieren.
7. Sensorfehler oder Kommunikationsausfall simulieren.
8. Quality Code und Alarmreaktion prüfen.
9. Zeitstempel und Aktualisierungsintervall kontrollieren.

Idealerweise werden mindestens ein niedriger, ein mittlerer und ein hoher Messwert geprüft. Dadurch fallen Skalierungs- und Vorzeichenfehler eher auf als bei einem einzigen Arbeitspunkt.

Typische Integrationsfehler

Fehlerbild	Wahrscheinliche Ursache	Sinnvolle Prüfung
Wert ist um ein Register verschoben	0- und 1-basierte Adressierung verwechselt	Handbuchadresse, Registertyp und Gateway-Offset vergleichen
Sehr große oder sehr kleine Zufallszahl	Falscher Datentyp oder falsche Word-Reihenfolge	Rohregister hexadezimal auswerten
Wert ist exakt um Faktor 10 oder 100 falsch	Skalierungsfaktor fehlt	Faktor und Dezimalstellen im Handbuch prüfen
Negative Werte erscheinen positiv	INT als UINT interpretiert	Vorzeichenbehafteten Datentyp einstellen
Wert ist konstant, obwohl sich der Prozess ändert	Falsches Register oder veralteter Wert	Rohregister während einer Prozessänderung beobachten
Dashboard zeigt Wert trotz Sensorausfall	Letzter Wert wird ohne Qualitätsstatus weiterverwendet	Timeout und Stale-Status konfigurieren
Einheit im Dashboard ist falsch	Geräteparametrierung und Gateway-Mapping stimmen nicht überein	Aktuelle Sensoreinheit und Mapping-Version vergleichen
Einzelne Geräte fallen sporadisch aus	Buslast, Verdrahtung oder Timeout ungeeignet	RS-485-Aufbau und Abfragezyklus prüfen

Praxisbeispiel: Druck- und Temperaturwerte im Dashboard falsch

In einer Wasseraufbereitungsanlage sollen ein Drucksensor und ein Temperaturmessumformer über Modbus RTU an ein Edge-Gateway angebunden werden. Die Kommunikation funktioniert sofort, die Werte im Dashboard sind jedoch unplausibel.

Der Temperaturmessumformer liefert im Register 30011 den Rohwert 253. Das Gateway übernimmt den Wert ohne Skalierung und zeigt 253 °C an. Laut Gerätehandbuch gilt jedoch ein Faktor von 0,1. Der richtige Messwert beträgt 25,3 °C.

Der Drucksensor überträgt einen FLOAT32-Wert über die Holding Register 40021 und 40022. Das Gateway erwartet als Startadresse einen nullbasierten Offset, eingetragen wurde jedoch 40021. Nach Korrektur auf Offset 20 werden die richtigen Register gelesen.

Der angezeigte Druck bleibt trotzdem unplausibel. Die Rohregister zeigen, dass die beiden 16-Bit-Wörter gegenüber der Gateway-Standardeinstellung vertauscht sind. Nach Aktivierung des Word Swap ergibt sich ein plausibler Wert von 6,42 bar.

Zusätzlich wird ein Statusregister eingebunden. Bit 2 meldet einen internen Sensorfehler. Das Gateway setzt bei diesem Bit den Quality Code auf „Bad“, statt den zuletzt gültigen Druckwert ohne Kennzeichnung weiterzusenden.

Für beide Messstellen wird anschließend eine Mapping-Tabelle erstellt. Sie enthält Registeradresse, Offset, Datentyp, Reihenfolge, Skalierung, Einheit, Statusbits, Abfrageintervall und Firmwarestand.

Nach der Korrektur werden drei Referenzpunkte geprüft und mit den lokalen Anzeigen verglichen. Erst danach wird das Mapping für den Produktivbetrieb freigegeben.

Empfohlener Integrationsablauf

1. Sensoren, Messstellen und Zielsystem vollständig erfassen.
2. Aktuelle Geräte- und Modbus-Handbücher beschaffen.
3. Firmwarestände dokumentieren.
4. Modbus RTU oder TCP und Kommunikationsparameter festlegen.
5. Registertyp, Adresse und Gateway-Offset zuordnen.
6. Registeranzahl und Datentyp definieren.
7. Byte- und Word-Reihenfolge anhand eines Referenzwerts prüfen.
8. Skalierungsfaktor, Offset und Einheit übernehmen.
9. Statusregister, Fehlerwerte und gültige Bereiche auswerten.
10. Abfrage- und Übertragungsintervall festlegen.
11. Zeitstempel- und Quality-Code-Konzept definieren.
12. Mapping im Edge-Gateway konfigurieren.
13. Rohwert, Gateway-Wert und Zielsystem miteinander vergleichen.
14. Kommunikations- und Sensorfehler gezielt simulieren.
15. Mapping-Tabelle versionieren und freigeben.

Welche Produkte und Lösungen eignen sich?

IIoT-Lösungen

Die Kategorie IIoT-Lösungen umfasst die Verbindung von Sensoren, Aktoren und Steuerungen mit Edge-Gateways, Leitständen, Datenbanken und Cloud-Plattformen.

Die Umsetzung kann unter anderem Geräteauswahl, Gateway-Konfiguration, Register-Mapping, Datenmodell, MQTT- beziehungsweise HTTPS-Anbindung, lokale Pufferung, Prüfung und Dokumentation umfassen.

Universal AI/DI Modul DMB 96500

Das DMB 96500 erfasst unterschiedliche Sensorsignale wie Widerstandsthermometer, Thermoelemente, Strom, Spannung, Widerstand, Frequenz und PWM.

Messwert und Konfiguration können über Modbus RTU ausgelesen beziehungsweise eingestellt werden. Das Modul eignet sich dadurch zur Integration vorhandener Sensoren in eine Modbus-basierte Datenerfassung.

4-Kanal-AI-Modul DMB 96200

Das DMB 96200 verfügt über vier galvanisch getrennte Analogeingänge. Die Kanäle lassen sich als Strom- oder Spannungseingänge konfigurieren und über Modbus RTU auslesen.

Die galvanische Trennung reduziert die Gefahr von Messfehlern durch Potenzialunterschiede und Störspannungen zwischen den angeschlossenen Signalkreisen.

4-Kanal-Analog-I/O-Modul DMB 96400

Das DMB 96400 bietet vier unabhängig konfigurierbare und galvanisch getrennte I/O-Kanäle. Je nach Kanal können analoge Eingangs- und Ausgangssignale sowie digitale Funktionen bereitgestellt werden.

Damit lassen sich bestehende analoge Mess- und Stellsignale in eine Modbus-RTU-Struktur einbinden.

Modbus RTU Anschlussmodul DMB 96000

Das DMB 96000 dient zum Anschluss von Modbus RTU und Versorgung an Installationen mit dem In-Rail-Bus-System.

Es unterstützt einen übersichtlichen Aufbau mehrerer Modbus-I/O-Module auf der Hutschiene und reduziert den Verdrahtungsaufwand innerhalb des Schaltschranks.

Fazit: Ein Modbus-Register ist noch kein fertiger IIoT-Messwert

Eine stabile Modbus-Kommunikation ist nur der erste Schritt der IIoT-Integration. Erst durch die korrekte Zuordnung von Registertyp, Adresse, Datentyp, Reihenfolge, Skalierung und Einheit entsteht ein fachlich nutzbarer Messwert.

Besonders häufig sind Fehler durch unterschiedliche Adresskonventionen, vertauschte Registerwörter und nicht berücksichtigte Skalierungsfaktoren. Diese Fehler erzeugen oft keine Kommunikationsmeldung und bleiben deshalb ohne Referenzprüfung lange unentdeckt.

Ein vollständiges Mapping umfasst zusätzlich Zeitstempel, gültigen Wertebereich, Fehlerwerte, Gerätestatus und Quality Code. Bei einem Sensor- oder Kommunikationsfehler darf der letzte gültige Wert nicht ohne Kennzeichnung weiterverarbeitet werden.

Die wichtigste Grundlage ist eine versionierte Mapping-Tabelle, die Gerätehandbuch, Firmware, Gateway-Konfiguration und Zielvariable eindeutig miteinander verbindet. Erst nach dem Vergleich mit bekannten Referenzwerten sollte das Mapping für den Produktivbetrieb freigegeben werden.

Häufige Fragen zur Modbus-IIoT-Integration

Warum zeigt das Gateway trotz funktionierender Kommunikation falsche Werte?

Häufig werden das falsche Register, ein ungeeigneter Datentyp, eine falsche Byte- oder Word-Reihenfolge oder ein fehlender Skalierungsfaktor verwendet.

Was ist der Unterschied zwischen Registeradresse und Offset?

Ein Gerätehandbuch kann beispielsweise eine Referenzadresse wie 40021 angeben, während das Gateway den nullbasierten Offset 20 erwartet. Welche Eingabe erforderlich ist, hängt von der Software ab.

Kann Modbus direkt eine Einheit übertragen?

Nur wenn das konkrete Gerät dafür ein eigenes Register oder Datenmodell bereitstellt. Häufig muss die Einheit aus der Geräteparametrierung beziehungsweise dem Handbuch übernommen und im Gateway ergänzt werden.

Wie erkenne ich die richtige Word-Reihenfolge?

Die Rohregister werden mit einem bekannten Messwert verglichen. Anschließend werden die möglichen Byte- und Word-Reihenfolgen getestet, bis der korrekt dargestellte Wert entsteht.

Was bedeutet ein Quality Code?

Der Quality Code zeigt, ob ein Messwert gültig, unsicher, fehlerhaft, veraltet oder aufgrund einer Kommunikationsstörung nicht verfügbar ist.

Soll der Rohwert ebenfalls gespeichert werden?

Für Diagnose und Inbetriebnahme ist dies häufig sinnvoll. Im normalen Betrieb kann der Rohwert optional gespeichert werden, während technischer Wert, Einheit und Qualitätsstatus immer eindeutig vorliegen sollten.

Wie schnell sollten Modbus-Sensoren abgefragt werden?

Das Intervall richtet sich nach Sensordynamik, interner Aktualisierungsrate, Buslast und benötigter Alarmreaktionszeit. Eine schnellere Abfrage als die interne Messwertaktualisierung liefert keine zusätzlichen Informationen.

Was passiert bei einem Kommunikationsausfall?

Das Gateway sollte den Wert nach einer definierten Zeit als veraltet oder fehlerhaft kennzeichnen. Der letzte Messwert darf nicht unbegrenzt als aktueller Wert weiterverwendet werden.

Muss jedes Gerät eine eigene Modbus-Adresse haben?

Bei mehreren Modbus-RTU-Geräten im selben Segment benötigt jeder Teilnehmer eine eindeutige Adresse. Doppelte Adressen führen zu Kommunikationsfehlern oder nicht eindeutig zuordenbaren Antworten.

Warum sollte das Mapping versioniert werden?

Firmwareänderungen, Geräteaustausch und neue Gateway-Konfigurationen können Register oder Skalierungen verändern. Eine Versionierung macht nachvollziehbar, welche Zuordnung zu welchem Anlagenstand gehört.