Modbus-TCP-Gateway überlastet: Polling-Intervall, Verbindungsanzahl und Timeout richtig dimensionieren

→ Produktkategorie: IIoT-Lösungen

Ein Modbus-TCP-Gateway funktioniert nach der Inbetriebnahme zunächst problemlos, doch mit jedem zusätzlichen Messgerät und jeder neuen Visualisierung werden die Antwortzeiten länger. Irgendwann erscheinen sporadische Timeouts, einzelne Messwerte bleiben stehen oder Clients melden Kommunikationsfehler, obwohl Ethernet-Verbindung und RS485-Verdrahtung grundsätzlich in Ordnung sind.

In vielen Fällen ist das Gateway nicht defekt. Stattdessen werden schlicht mehr Modbus-Transaktionen angefordert, als die gesamte Kommunikationskette in der verfügbaren Zeit abarbeiten kann.

Besonders kritisch wird dies bei Gateways zwischen Ethernet und einer seriellen RS485-Strecke. Auf der Ethernet-Seite können mehrere Clients innerhalb kürzester Zeit Anfragen erzeugen. Auf der seriellen Seite müssen diese Zugriffe jedoch häufig nacheinander zu den einzelnen Modbus-RTU-Teilnehmern übertragen und beantwortet werden.

Die verfügbare Netzwerkbandbreite des Ethernet-Anschlusses ist deshalb bei einem Modbus-TCP/RS485-Gateway häufig nicht der eigentliche Engpass. Entscheidend sind die Anzahl der Transaktionen, die Antwortzeiten der Feldgeräte, die serielle Baudrate, die Anzahl der abgefragten Registerblöcke und das Verhalten der Clients bei Timeouts.

Ein passendes konkretes Produkt für solche Anwendungen ist der bei ICS Schneider angebotene IF2E011 – Konverter Ethernet / RS485. Er verbindet eine Ethernet-/TCP-IP-Kommunikation mit einer RS485-Schnittstelle und eignet sich damit für die Integration serieller Messgeräte in ein IP-basiertes Netzwerk.

Weitere Lösungen für die übergeordnete Datenintegration finden Sie unter IIoT-Lösungen bei ICS Schneider.

Warum kann ein Modbus-TCP-Gateway überlastet werden?

Modbus TCP arbeitet nach einem Client-/Server-Prinzip. Ein Client sendet eine Anfrage und erwartet anschließend die dazugehörige Antwort.

Ein Gateway zwischen Modbus TCP und Modbus RTU muss dabei mehrere Aufgaben übernehmen. Es empfängt die TCP-Anfrage, interpretiert den Modbus-Telegrammteil, leitet die Kommunikation auf die serielle Seite weiter, wartet auf die Antwort des adressierten RS485-Teilnehmers und überträgt diese anschließend wieder zum TCP-Client.

Dadurch treffen zwei unterschiedlich arbeitende Kommunikationswelten aufeinander.

Auf Ethernet können neue Requests sehr schnell eintreffen. Auf einer seriellen RS485-Leitung steht dagegen nur eine begrenzte Übertragungskapazität zur Verfügung.

Ein typischer Engpass entsteht deshalb nach dem Prinzip

viele schnelle TCP-Anfragen → Warteschlange im Gateway → serielle Abarbeitung → längere Antwortzeiten → Client-Timeouts

Wird darauf mit Retries reagiert

kann daraus werden:

Timeout → Retry → zusätzliche Anfrage → noch längere Warteschlange → weiterer Timeout

Das Ergebnis

ist eine Kommunikationskette, die durch ihre eigene Fehlerbehandlung immer stärker belastet wird.

Warum Ethernet und RS485 unterschiedlich schnell sind

Ein häufiger Denkfehler besteht darin, die Leistungsfähigkeit eines Gateways anhand seiner Ethernet-Schnittstelle zu beurteilen.

Bei einem Ethernet-/RS485-Gateway kann die Ethernet-Seite jedoch wesentlich schneller sein als die angeschlossene serielle Kommunikation.

Beispiel

Eine RS485-Strecke arbeitet mit:

19.200 bit/s

Eine Ethernet-Verbindung arbeitet dagegen

um mehrere Größenordnungen schneller.

Das bedeutet

Der Ethernet-Client kann neue Anfragen schneller erzeugen, als das Gateway sie auf der seriellen Seite beantworten lassen kann.

Die eigentliche Kapazität der Messkette wird deshalb häufig bestimmt durch

• RS485-Baudrate,
• Telegrammlänge,
• Antwortzeit des Feldgeräts,
• notwendige Telegrammpausen,
• Anzahl der Feldgeräte,
• Anzahl der Registerblöcke pro Gerät.

Was ist eine Modbus-Transaktion?

Eine Modbus-Abfrage besteht im einfachsten Fall aus einer Anfrage des Clients und einer Antwort des Servers beziehungsweise Feldgeräts.

Beispiel

Der Client möchte mehrere Holding Register lesen und sendet:

Function Code 03 – Read Holding Registers

Das adressierte Gerät antwortet

mit den angeforderten Registerwerten.

Eine vollständige Transaktion besteht damit vereinfacht aus

Request → Verarbeitung → Response

Bei einem Gateway kommt zusätzlich hinzu

TCP Request → Gateway → RTU Request → Feldgerät → RTU Response → Gateway → TCP Response

Die entscheidende Größe ist deshalb nicht nur

wie viele Geräte angeschlossen sind

sondern

wie viele Transaktionen pro Sekunde erzeugt werden

Was bedeutet Polling-Intervall?

Modbus arbeitet typischerweise nicht ereignisgesteuert. Ein Client fragt die benötigten Werte regelmäßig ab.

Dieser Vorgang wird als:

Polling

bezeichnet.

Bei einem Polling-Intervall von 1 Sekunde

wird ein definierter Registerbereich beispielsweise:

1 × pro Sekunde

abgefragt.

Bei 100 ms

entstehen dagegen:

10 Abfragen pro Sekunde

Das klingt zunächst wenig

Multipliziert sich jedoch sehr schnell mit:

• der Anzahl der Geräte,
• der Anzahl der Registerblöcke,
• der Anzahl der Clients.

Wie viele Requests entstehen tatsächlich?

Die tatsächliche Request-Rate lässt sich überschlägig berechnen.

Vereinfacht gilt

Requests/s = Geräte × Registerblöcke je Gerät × Polls/s × Clients

Beispiel

Es sind 20 Geräte angeschlossen.

Jedes Gerät wird mit vier separaten Registerabfragen gelesen.

Polling-Intervall:

500 ms = 2 Polls/s

Ein einzelner Client erzeugt damit

20 × 4 × 2 = 160 Requests/s

Greift zusätzlich ein zweiter Client unabhängig auf dieselben Geräte zu

können daraus theoretisch bereits:

320 Requests/s

werden.

Für eine serielle RS485-Strecke

kann eine solche Last völlig unrealistisch sein, obwohl ein Ethernet-Netzwerk diese Anzahl kleiner TCP-Telegramme problemlos übertragen könnte.

Register sinnvoll zu Blöcken zusammenfassen

Einer der wirkungsvollsten Ansätze zur Reduzierung der Kommunikationslast ist die Optimierung der Registerabfragen.

Ungünstig wäre beispielsweise

fünf benachbarte Register mit fünf einzelnen Requests auszulesen.

Besser ist

einen zusammenhängenden Block zu lesen, wenn das Registermodell des Feldgeräts dies zulässt.

Mit Function Code 03

können nach Modbus-Spezifikation bis zu:

125 zusammenhängende Holding Register

in einer Anfrage adressiert werden.

Das bedeutet jedoch nicht

dass immer möglichst große Blöcke gelesen werden sollten.

Eine sinnvolle Strategie ist

benötigte benachbarte Werte zusammenzufassen und unnötige Register nicht permanent mitzulesen.

Beispiel

Statt:

Register 100 → Request 1

Register 101 → Request 2

Register 102 → Request 3

Register 103 → Request 4

kann häufig verwendet werden

Register 100 … 103 → ein Request

Damit sinkt

die Anzahl der Transaktionen um:

75 %

für diese vier Werte.

Messwerte mit unterschiedlichen Pollingraten erfassen

Nicht jeder Messwert einer Anlage muss gleich häufig aktualisiert werden.

Ein schnell veränderlicher Prozesswert kann eine deutlich höhere Aktualisierungsrate benötigen als eine Gerätetemperatur, ein Betriebsstundenzähler oder eine Diagnoseinformation.

Als technische Startwerte können beispielsweise unterschiedliche Klassen verwendet werden

Datenart	Möglicher Startbereich	Beispiel
Schneller Prozesswert	100 … 500 ms	Nur wenn die Prozessdynamik dies tatsächlich erfordert
Normale Prozessüberwachung	500 ms … 2 s	Typische Visualisierung
Langsam veränderliche Messwerte	5 … 30 s	Temperatur, Energie, Betriebszustände
Diagnoseinformationen	10 … 300 s	Gerätestatus, Betriebsstunden, Konfigurationswerte

Wichtig

Diese Werte sind keine Modbus-Vorgabe, sondern lediglich mögliche Ausgangspunkte für die Auslegung.

Das tatsächlich erforderliche Intervall muss aus:

Prozessdynamik + Regelungsanforderung + Datenbedarf + verfügbarer Kommunikationsleistung

abgeleitet werden.

Mehrere Modbus-TCP-Clients richtig berücksichtigen

In modernen Anlagen greifen häufig mehrere Systeme auf dieselbe Modbus-Kommunikation zu.

Beispiele sind

• SPS,
• SCADA,
• Visualisierung,
• Historian,
• Service-PC,
• IIoT-Datenerfassung.

Problematisch wird es

wenn jedes dieser Systeme unabhängig dieselben Register liest.

Beispiel

Ein Feldgerät wird alle 500 ms abgefragt von:

• einer SPS,
• einer Visualisierung,
• einem Datenlogger.

Dann entstehen

für denselben Prozesswert unter Umständen drei getrennte Modbus-Anfragen.

Bei einem transparenten Gateway

kann jede dieser Anfragen eine neue Kommunikation auf der seriellen Seite verursachen, sofern das Gateway keine entsprechende Datenpufferung beziehungsweise Caching-Funktion besitzt.

Eine bessere Architektur kann deshalb sein

Feldgerät → zentraler Datensammler → mehrere Verbraucher

anstatt:

Feldgerät ← mehrere unabhängig pollende Clients

TCP-Verbindungen und Transaktionen unterscheiden

Eine TCP-Verbindung ist nicht dasselbe wie eine Modbus-Transaktion.

TCP-Verbindung

beschreibt die Kommunikationsverbindung zwischen zwei Netzwerkpartnern.

Modbus-Transaktion

beschreibt eine einzelne Request-/Response-Kommunikation innerhalb dieser Verbindung.

Ein einzelner Client kann deshalb

über eine bestehende TCP-Verbindung zahlreiche Modbus-Transaktionen nacheinander durchführen.

Für die maximale Anzahl von TCP-Verbindungen

gibt es keinen universellen Wert, der für alle Modbus-TCP-Geräte gilt.

Die zulässige Anzahl hängt von:

• TCP/IP-Stack,
• Arbeitsspeicher,
• Prozessorleistung,
• Firmware,
• Gateway-Architektur

des konkreten Geräts ab.

Auch die Zahl gleichzeitig verarbeitbarer Modbus-Transaktionen

ist gerätespezifisch.

Eine hohe Zahl angeschlossener oder erreichbarer Geräte darf deshalb nicht mit einer beliebig hohen Zahl paralleler Requests gleichgesetzt werden.

TCP-Verbindungen nicht für jeden Request neu aufbauen

Für eine zyklische Modbus-TCP-Kommunikation ist es normalerweise effizienter, eine bestehende TCP-Verbindung weiterzuverwenden.

Ungünstig wäre

TCP öffnen → Register lesen → TCP schließen → TCP öffnen → nächstes Register lesen

Besser ist normalerweise

TCP öffnen → mehrere Modbus-Transaktionen → Verbindung bestehen lassen

Dadurch werden

• zusätzliche TCP-Handshakes,
• Verbindungsaufbauzeiten,
• zusätzliche Socket-Ressourcen

reduziert.

Das entspricht auch

der grundsätzlichen Empfehlung für Modbus-TCP-Implementierungen, Verbindungen nicht für jede einzelne Transaktion neu aufzubauen.

Timeout richtig einstellen

Ein Modbus-Timeout definiert, wie lange ein Client auf die Antwort zu einer Anfrage wartet.

Ein zu kurzer Timeout

kann dazu führen, dass eine eigentlich korrekte Antwort als Fehler bewertet wird, nur weil:

• andere Requests vorher abgearbeitet werden,
• der serielle Teilnehmer langsam antwortet,
• das Gateway eine Warteschlange besitzt,
• das Netzwerk zusätzliche Laufzeit verursacht.

Ein zu langer Timeout

ist ebenfalls ungünstig.

Dann kann ein tatsächlich ausgefallenes Gerät die Kommunikation unnötig lange blockieren beziehungsweise die Fehlererkennung stark verzögern.

Der Timeout sollte deshalb größer sein als

erwartete maximale normale Antwortzeit

und gleichzeitig klein genug

um einen echten Kommunikationsausfall innerhalb der erforderlichen Zeit zu erkennen.

Eine universelle Einstellung wie

100 ms

oder:

1 s

ist deshalb nicht für jede Anlage richtig.

Warum zu viele Retries das Problem verschärfen

Wenn ein Client keine Antwort innerhalb des Timeouts erhält, kann er die Anfrage wiederholen.

Ein Retry ist grundsätzlich sinnvoll

weil eine einzelne Kommunikation beispielsweise durch eine kurzzeitige Störung verloren gehen kann.

Kritisch wird es jedoch

wenn ein bereits überlastetes Gateway mit sehr kurzen Timeouts und mehreren direkten Retries betrieben wird.

Dann kann folgende Situation entstehen

Request 1 wartet noch in der Queue

→ Client Timeout

→ Retry 1

→ noch mehr Queue

→ zweiter Timeout

→ Retry 2

Die Fehlerbehandlung erzeugt dann

zusätzliche Last genau in dem Moment, in dem die Kommunikationsstrecke bereits ausgelastet ist.

Sinnvoller ist

eine abgestimmte Kombination aus:

• realistischem Timeout,
• begrenzter Retry-Anzahl,
• Verzögerung zwischen Wiederholungen,
• klarer Fehlerbehandlung nach mehreren erfolglosen Versuchen.

Timeout-Kaskaden verstehen

Bei mehreren Kommunikationsebenen können verschiedene Timeouts gleichzeitig aktiv sein.

Beispiel

SCADA → Modbus-TCP-Gateway → RS485-Feldgerät

Dabei können existieren

• TCP-Client-Timeout,
• Gateway-Timeout zur seriellen Seite,
• Antwortüberwachung des Feldgeräts,
• Retry-Mechanismus des Clients.

Diese Zeiten müssen zueinander passen

Wenn beispielsweise das Gateway intern:

500 ms

auf ein Feldgerät wartet, der übergeordnete Client aber bereits nach:

300 ms

einen Retry sendet, entsteht eine ungünstige Konfiguration.

Grundsätzlich sollte gelten

übergeordneter Timeout > maximal erwartete Bearbeitungszeit der darunterliegenden Kommunikationsstufe

Polling zeitlich staffeln

Selbst eine insgesamt moderate Pollingrate kann zu Problemen führen, wenn alle Clients ihre Anfragen exakt gleichzeitig senden.

Ein typischer Fall

ist eine Visualisierung, die jede Sekunde gleichzeitig:

50 Messstellen

aktualisiert.

Dann entsteht jede Sekunde

ein kurzer Request-Burst.

Besser ist

die Abfragen zeitlich zu verteilen.

Beispielsweise

Gerät 1 → t = 0 ms

Gerät 2 → t = 50 ms

Gerät 3 → t = 100 ms

...

Dadurch

wird nicht unbedingt die Gesamtzahl der Requests reduziert, aber die Spitzenlast am Gateway sinkt.

Serielle Übertragungszeit abschätzen

Bei einem Gateway auf eine Modbus-RTU-Strecke kann bereits eine überschlägige Zeitberechnung zeigen, ob eine gewünschte Pollingrate überhaupt realistisch ist.

Bei 19.200 bit/s

benötigt bereits die reine Übertragung eines einzelnen Bytes einschließlich Start-, Daten- und Stopbits eine endliche Zeit.

Ein typischer Read-Request

und seine Antwort können zusammen beispielsweise einige Dutzend Bytes umfassen.

Vereinfacht gilt

tÜbertragung ≈ übertragene Bits / Baudrate

Hinzu kommen

• Telegrammpausen,
• Verarbeitungszeit des Slaves,
• Gateway-Verarbeitung,
• eventuelle Wartezeiten durch andere Requests.

Beispielhaft

kann eine einzelne komplette Transaktion auf einer 19.200-bit/s-Strecke durchaus Größenordnungen von:

20 … 30 ms

oder mehr beanspruchen.

Der tatsächliche Wert hängt jedoch vollständig von Telegrammlänge und Gerät ab.

Bei 30 ms je Transaktion

wären theoretisch:

1 s / 0,03 s ≈ 33 Transaktionen/s

möglich, bevor weitere Reserven berücksichtigt werden.

Eine Planung exakt bis 100 %

ist nicht sinnvoll.

Es muss Reserve für:

• schwankende Antwortzeiten,
• Retries,
• Diagnosezugriffe,
• temporäre Netzwerkbelastung

vorhanden sein.

Gateway-Auslastung überschlägig berechnen

Für eine erste Plausibilitätsprüfung kann eine vereinfachte Auslastungsbetrachtung verwendet werden.

Vereinfacht

Auslastung ≈ Requests/s × mittlere Transaktionsdauer

Beispiel

Es entstehen:

25 Requests/s

Die durchschnittliche serielle Transaktion benötigt

25 ms

Dann ergibt sich näherungsweise

25 × 0,025 s = 0,625

beziehungsweise:

62,5 %

Dieser Wert ist keine exakte Gateway-CPU-Auslastung

sondern beschreibt lediglich, welcher Anteil der verfügbaren Kommunikationszeit bereits benötigt wird.

Steigt dieser Wert dauerhaft in Richtung 100 %

nimmt die Warteschlangenbildung stark zu.

Für eine robuste Anlage

sollte deshalb bewusst Kommunikationsreserve eingeplant werden.

Unit Identifier und Teilnehmerzuordnung

Bei einem Modbus-TCP/RTU-Gateway muss eine TCP-Anfrage dem richtigen seriellen Teilnehmer zugeordnet werden.

Dafür spielt insbesondere der:

Unit Identifier

eine wichtige Rolle.

Bei einem direkten Modbus-TCP-Gerät

ist dieser Wert je nach Implementierung weniger relevant.

Bei einem Gateway

kann er dagegen zur Adressierung des nachgeschalteten Modbus-RTU-Teilnehmers dienen.

Deshalb muss sichergestellt sein

dass:

• jede erforderliche Geräteadresse eindeutig ist,
• Gateway-Mapping und RTU-Adresse übereinstimmen,
• keine doppelten Teilnehmeradressen vorhanden sind.

Eine falsche Zuordnung

kann ähnliche Symptome verursachen wie eine Überlast:

• Timeouts,
• sporadisch fehlende Werte,
• Antworten vom falschen Teilnehmer.

Netzwerkprobleme von Gateway-Überlast unterscheiden

Nicht jeder Modbus-TCP-Timeout wird durch eine zu hohe Pollingrate verursacht.

Weitere mögliche Ursachen sind

• IP-Adresskonflikte,
• fehlerhafte Subnetzkonfiguration,
• instabile Switch-Verbindung,
• Firewall-Regeln,
• VLAN-Konfiguration,
• doppelte Modbus-Adressen auf RS485,
• fehlerhafte Terminierung,
• EMV-Probleme auf der seriellen Leitung.

Ein wichtiger diagnostischer Hinweis ist

wenn sich die Kommunikation deutlich verbessert, sobald:

Polling-Intervall erhöht

oder:

Anzahl paralleler Clients reduziert

wird.

Dann spricht vieles dafür

dass die Kommunikationslast zumindest einen wesentlichen Anteil am Problem besitzt.

Überlastung systematisch diagnostizieren

Eine zielführende Diagnose beginnt mit einer Bestandsaufnahme der tatsächlich erzeugten Kommunikation.

Erfasst werden sollten

• Anzahl der Modbus-TCP-Clients,
• Anzahl der angeschlossenen Feldgeräte,
• Polling-Intervall jedes Clients,
• Anzahl der Requests je Pollingzyklus,
• Baudrate der RS485-Seite,
• mittlere Antwortzeit,
• maximale Antwortzeit,
• Timeout-Einstellung,
• Retry-Anzahl.

Anschließend sollte

die Pollingrate schrittweise reduziert werden.

Wenn beispielsweise

bei:

250 ms

regelmäßig Fehler auftreten, bei:

1 s

aber nicht mehr, ist dies ein deutlicher Hinweis auf eine Kapazitätsgrenze der Kommunikationskette.

Typische Fehler bei überlasteter Modbus-Kommunikation

Beobachtung	Mögliche Ursache	Sinnvolle Prüfung
Messwerte aktualisieren sich zunehmend langsamer	Warteschlange im Gateway	Pollingrate und Anzahl der Requests reduzieren
Sporadische Timeouts bei vielen Messstellen	Kommunikationskapazität erreicht	Gesamtzahl Requests/s berechnen
Kommunikation funktioniert mit einem Client, aber nicht mit drei Clients	Mehrfaches Polling derselben Feldgeräte	Clients einzeln aktivieren und Last vergleichen
Timeouts nehmen nach dem ersten Fehler stark zu	Retry-Sturm	Timeout und Retry-Strategie prüfen
Fehler treten jede Sekunde periodisch auf	Synchron gestartete Pollingzyklen	Anfragen zeitlich staffeln
Ein langsamer Teilnehmer beeinträchtigt andere Geräte	Serielle Kommunikation wird durch Wartezeit blockiert	Antwortzeit und Timeout dieses Teilnehmers prüfen
Viele Einzelregister werden gelesen	Unnötig hohe Request-Zahl	Zusammenhängende Registerblöcke bilden
Gateway reagiert nach Service-PC-Anschluss instabil	Zusätzlicher Modbus-TCP-Client erhöht Last	Service-Polling deaktivieren oder Intervall erhöhen
Ethernet ist schnell, Messwerte aber trotzdem langsam	RS485-Seite bildet Engpass	Serielle Transaktionszeit berechnen
Hohe Fehlerquote nur bei 9.600 bit/s	Pollingrate passt nicht zur seriellen Übertragungszeit	Baudrate und Pollingbudget prüfen
Änderung des Timeouts verschlechtert das Problem	Retry-Mechanismus erzeugt zusätzliche Last	Timeout größer als normale maximale Antwortzeit wählen
Einige Clients verlieren TCP-Verbindungen	Verbindungs- oder Ressourcenlimit möglich	Maximale Client-/Verbindungszahl des Gateways prüfen

Polling schrittweise optimieren

1. Netzwerkstruktur dokumentieren: Alle TCP-Clients, Gateway und seriellen Teilnehmer erfassen.
2. RS485-Baudrate feststellen: Die serielle Seite bestimmt häufig den wesentlichen Durchsatz.
3. Pollingintervalle erfassen: Nicht nur den Hauptclient, sondern auch SCADA, Service und Datenlogger berücksichtigen.
4. Requests pro Zyklus zählen: Einzelregister und Registerblöcke getrennt erfassen.
5. Gesamte Request-Rate berechnen: Geräte × Blöcke × Pollingrate × Clients.
6. Zusammenhängende Register bündeln: Wo möglich mehrere benötigte Werte mit einer Anfrage lesen.
7. Unnötige Register entfernen: Diagnose- und Konfigurationsdaten nicht mit Prozessgeschwindigkeit pollen.
8. Daten nach Aktualitätsbedarf klassifizieren: Schnelle, normale und langsame Werte unterscheiden.
9. Pollingintervalle erhöhen: Nur so schnell abfragen, wie es die Anwendung tatsächlich benötigt.
10. Requests zeitlich staffeln: Gleichzeitige Lastspitzen vermeiden.
11. Anzahl der Clients reduzieren: Wenn möglich eine zentrale Datenerfassung verwenden.
12. TCP-Verbindungen wiederverwenden: Verbindung nicht für jede Transaktion neu aufbauen.
13. Antwortzeiten messen: Mittelwert und ungünstigsten normalen Fall erfassen.
14. Timeout passend einstellen: Oberhalb der normalen maximalen Antwortzeit wählen.
15. Retries begrenzen: Keine aggressiven Wiederholungsschleifen konfigurieren.
16. Problemgeräte separat prüfen: Ein langsamer RTU-Teilnehmer kann den gesamten Zyklus verlängern.
17. Kommunikationsreserve einplanen: System nicht dauerhaft an der theoretischen Kapazitätsgrenze betreiben.
18. Optimierung dokumentieren: Pollingrate, Registerbereiche, Timeouts und Retry-Werte festhalten.

Praxisbeispiel: 20 Messgeräte hinter einem Gateway

In einer Anlage sind 20 Modbus-RTU-Messgeräte über RS485 an ein Ethernet-/RS485-Gateway angeschlossen. Ein SCADA-System liest die Daten über Modbus TCP aus.

Ursprüngliche Konfiguration

Für jedes Gerät werden vier getrennte Registerbereiche gelesen.

Polling-Intervall:

250 ms

Das entspricht

4 Pollingzyklen/s

Die Request-Rate beträgt damit

20 Geräte × 4 Registerblöcke × 4 Polls/s

= 320 Requests/s

Die Folge

Das Ethernet-Netzwerk zeigt keine auffällige Auslastung, trotzdem treten:

• Modbus-Timeouts,
• veraltete Messwerte,
• sporadische Kommunikationsalarme

auf.

Bei der Analyse

wird erkannt, dass ein großer Teil der Register jedes Geräts direkt nebeneinander liegt.

Die vier Requests werden deshalb

zu einem sinnvollen zusammenhängenden Registerblock zusammengefasst.

Die neue Pollingrate

wird für diese Prozesswerte auf:

1 s

gesetzt.

Damit entstehen nur noch

20 Geräte × 1 Block × 1 Poll/s

= 20 Requests/s

Die Zahl der Transaktionen sinkt damit von

320 Requests/s

auf:

20 Requests/s

Das entspricht

einer Reduzierung der Request-Rate um:

93,75 %

Zusätzlich

werden langsam veränderliche Diagnosewerte nur noch alle 30 Sekunden gelesen und die Geräteabfragen zeitlich über den Zyklus verteilt.

Ergebnis

Die Kommunikationsprobleme verschwinden, obwohl weder Gateway noch RS485-Verkabelung ausgetauscht werden. Entscheidend war nicht mehr Netzwerkbandbreite, sondern eine zur realen Kommunikationskette passende Pollingstrategie.

IF2E011 – Konverter Ethernet / RS485 bei ICS Schneider

Für die Kopplung serieller RS485-Geräte mit einem Ethernet-Netzwerk führt ICS Schneider den:

IF2E011 – Konverter Ethernet / RS485

als eigenes Produkt.

ICS nennt für den IF2E011 unter anderem

• Umwandlung Ethernet / RS485,
• TCP/IP-Kommunikation,
• bis zu 254 Geräte im Netzwerk je Konverter,
• Hilfsspannung 80 … 270 VAC,
• kompakte Ausführung mit 2 Modulen für die Hutschienenmontage.

Für die Anwendung besonders wichtig

ist die Unterscheidung zwischen:

maximal adressierbarer beziehungsweise angebundener Gerätezahl

und:

tatsächlich erreichbarer Aktualisierungsrate

Eine große mögliche Teilnehmerzahl bedeutet nicht

dass alle Teilnehmer gleichzeitig mit extrem kurzen Intervallen abgefragt werden können.

Die tatsächlich erreichbare Kommunikationsleistung wird weiterhin beeinflusst durch

• RS485-Baudrate,
• Antwortzeit der angeschlossenen Geräte,
• Registeranzahl,
• Pollingstrategie,
• Anzahl der TCP-Clients,
• Timeout- und Retry-Einstellungen.

Der IF2E011 eignet sich deshalb insbesondere

für Anwendungen, in denen vorhandene serielle Messgeräte über ein IP-Netzwerk in:

• Visualisierungen,
• Energiemanagement,
• Automatisierungssysteme,
• übergeordnete Datenerfassung

integriert werden sollen.

Bei größeren Installationen

sollte die Kommunikationsarchitektur bereits vor der Inbetriebnahme anhand der tatsächlich benötigten:

Geräte × Register × Aktualisierungsraten × Clients

ausgelegt werden.

Fazit

Ein langsames oder scheinbar instabiles Modbus-TCP-Gateway ist nicht automatisch defekt. Häufig entsteht das Problem dadurch, dass auf der schnellen Ethernet-Seite mehr Requests erzeugt werden, als die nachgeschaltete Kommunikation in derselben Zeit verarbeiten kann.

Die Teilnehmerzahl allein reicht zur Auslegung nicht aus

Entscheidend ist:

Anzahl der Transaktionen pro Sekunde

Register sollten sinnvoll gebündelt werden

Mehrere zusammenhängende Werte lassen sich häufig mit einem gemeinsamen Modbus-Request auslesen.

Nicht jeder Wert benötigt dieselbe Pollingrate

Schnelle Prozesswerte und langsam veränderliche Diagnoseinformationen sollten unterschiedliche Aktualisierungsintervalle erhalten.

Mehrere Clients vervielfachen die Kommunikationslast

Besonders dann, wenn jeder Client dieselben Feldgeräte unabhängig abfragt.

Der Timeout muss zur realen Messkette passen

Ein zu kurzer Timeout erzeugt unnötige Retries. Ein zu langer Timeout verzögert dagegen die Fehlererkennung.

Retries müssen kontrolliert eingesetzt werden

In einer bereits ausgelasteten Kommunikation können aggressive Wiederholungen die Situation weiter verschlechtern.

Der IF2E011 bietet eine konkrete Ethernet-/RS485-Schnittstelle

für die Integration serieller Geräte in TCP/IP-basierte Netzwerke. Die verfügbare Teilnehmerzahl ersetzt jedoch keine Auslegung der erforderlichen Kommunikationsleistung.

Für die Praxis gilt

Alle Clients erfassen → angeschlossene Teilnehmer bestimmen → RS485-Baudrate prüfen → benötigte Register dokumentieren → zusammenhängende Register bündeln → tatsächliche Requests pro Sekunde berechnen → Daten nach Aktualitätsbedarf klassifizieren → Pollingintervalle passend wählen → Abfragen zeitlich staffeln → TCP-Verbindungen möglichst bestehen lassen → reale Antwortzeiten messen → Timeout oberhalb der normalen maximalen Antwortzeit einstellen → Retries begrenzen → Kommunikationsreserve vorsehen → Änderungen dokumentieren und anschließend unter realer Anlagenlast testen.

FAQ: Modbus-TCP-Gateway, Polling und Timeout richtig einstellen

Warum wird mein Modbus-TCP-Gateway langsam?

Häufig werden mehr Requests erzeugt, als das Gateway beziehungsweise die nachgeschaltete serielle Kommunikation innerhalb der verfügbaren Zeit verarbeiten kann.

Ist Ethernet bei einem Modbus-TCP/RTU-Gateway meistens der Engpass?

Nicht unbedingt. Bei einer Kopplung auf RS485 ist häufig die serielle Seite mit ihrer niedrigeren Datenrate und den Antwortzeiten der Feldgeräte der entscheidende Engpass.

Was bedeutet Polling bei Modbus?

Ein Client fragt Register eines Modbus-Geräts regelmäßig aktiv ab. Dieses zyklische Lesen wird als Polling bezeichnet.

Was ist ein gutes Modbus-Polling-Intervall?

Es gibt keinen universellen Wert. Das Intervall muss zur Prozessdynamik und zur Kapazität der Kommunikationsstrecke passen.

Muss ich jeden Messwert alle 100 ms lesen?

Nein. Viele Temperatur-, Energie-, Diagnose- oder Statuswerte ändern sich wesentlich langsamer und können entsprechend seltener abgefragt werden.

Wie berechne ich die ungefähre Zahl der Modbus-Requests?

Vereinfacht mit Requests/s = Geräte × Registerblöcke je Gerät × Polls/s × Clients.

Warum sollte ich zusammenhängende Register gemeinsam lesen?

Dadurch kann die Zahl einzelner Modbus-Transaktionen deutlich reduziert werden.

Wie viele Holding Register kann Function Code 03 lesen?

Die Modbus-Spezifikation erlaubt mit Function Code 03 bis zu 125 zusammenhängende Holding Register pro Request. Das konkrete Feldgerät muss den gewünschten Registerbereich natürlich ebenfalls unterstützen.

Sollte ich deshalb immer 125 Register gleichzeitig lesen?

Nein. Es sollten sinnvoll zusammenhängende und tatsächlich benötigte Register gebündelt werden. Unnötig große Datenblöcke erhöhen wiederum Telegrammlänge und Verarbeitungsaufwand.

Warum verursachen mehrere Modbus-TCP-Clients Probleme?

Wenn mehrere Clients dieselben Feldgeräte unabhängig pollen, kann sich die Zahl der Anfragen vervielfachen.

Gibt es eine feste maximale Anzahl von Modbus-TCP-Clients?

Nein. Die maximale Zahl gleichzeitiger Verbindungen ist geräte- und implementierungsabhängig.

Ist eine TCP-Verbindung dasselbe wie eine Modbus-Transaktion?

Nein. Innerhalb einer bestehenden TCP-Verbindung können viele Modbus-Request-/Response-Transaktionen übertragen werden.

Sollte die TCP-Verbindung nach jedem Modbus-Request geschlossen werden?

Bei zyklischer Kommunikation normalerweise nicht. Das Wiederverwenden einer bestehenden Verbindung reduziert unnötigen Verbindungsaufwand.

Was ist ein Modbus-Timeout?

Der Timeout ist die Zeit, die ein Client auf die Antwort einer Anfrage wartet, bevor er die Kommunikation als fehlgeschlagen bewertet.

Wie lang sollte der Timeout eingestellt werden?

Er sollte oberhalb der maximal zu erwartenden normalen Antwortzeit der gesamten Kommunikationskette liegen und gleichzeitig eine ausreichend schnelle Fehlererkennung ermöglichen.

Gibt Modbus einen festen Timeout vor?

Nein. Die Modbus-TCP-Spezifikation legt bewusst keinen universellen Transaktions-Timeout fest, weil die möglichen Netzwerk- und Anwendungsbedingungen sehr unterschiedlich sind.

Was passiert bei einem zu kurzen Timeout?

Normale, aber etwas verzögerte Antworten werden als Fehler interpretiert. Dadurch können unnötige Retries entstehen.

Was passiert bei einem zu langen Timeout?

Ein ausgefallenes Feldgerät kann die Fehlererkennung und gegebenenfalls weitere Kommunikationsabläufe unnötig verzögern.

Warum können Retries ein Gateway zusätzlich überlasten?

Jeder Retry erzeugt einen weiteren Request. Bei bereits vorhandener Warteschlange steigt die Last dadurch noch weiter.

Wie viele Retries sind sinnvoll?

Das hängt von der Anwendung ab. Die Anzahl sollte begrenzt sein und zum Timeout- und Fehlerkonzept passen. Aggressive Endlosschleifen sind zu vermeiden.

Was ist ein Retry-Sturm?

Mehrere Clients laufen gleichzeitig in einen Timeout und wiederholen ihre Requests. Dadurch steigt die Last weiter an und es entstehen noch mehr Timeouts.

Warum sollte Polling zeitlich gestaffelt werden?

Damit nicht alle Geräte gleichzeitig zum Beginn eines festen Zeitintervalls abgefragt werden und kurzfristige Lastspitzen entstehen.

Wie erkenne ich, ob die RS485-Seite der Engpass ist?

Wenn sich die Kommunikation durch längere Pollingintervalle, weniger Registerabfragen oder eine höhere zulässige Baudrate deutlich verbessert, ist die serielle Kommunikationskapazität ein wahrscheinlicher Faktor.

Kann ein einzelnes langsames Feldgerät alle anderen beeinflussen?

Ja. Wenn das Gateway lange auf dessen Antwort wartet, kann sich die Bearbeitung nachfolgender Requests verzögern.

Warum sollte ich Diagnosewerte seltener pollen?

Viele Diagnosewerte ändern sich nur langsam. Ein schnelles zyklisches Lesen liefert kaum zusätzlichen Nutzen, erzeugt aber Kommunikationslast.

Kann ich Modbus-Daten zentral erfassen und anschließend mehrfach weiterverwenden?

Ja. Eine zentrale Datenerfassung kann verhindern, dass mehrere übergeordnete Systeme dieselben Feldgeräte unabhängig mit hoher Frequenz abfragen.

Was bedeutet Modbus Unit Identifier?

Der Unit Identifier dient unter anderem bei Gateway-Anwendungen dazu, eine Modbus-TCP-Anfrage einem nachgeschalteten seriellen Teilnehmer zuzuordnen.

Kann eine falsche Geräteadresse wie eine Überlast aussehen?

Ja. Falsche beziehungsweise doppelte Adressen können Timeouts und Kommunikationsfehler verursachen und müssen deshalb vor einer Performanceanalyse ausgeschlossen werden.

Wie kann ich Gateway-Überlast von einem Netzwerkfehler unterscheiden?

Eine schrittweise Reduzierung der Pollinglast ist hilfreich. Verschwinden die Fehler bei längeren Intervallen oder weniger Clients, deutet dies auf ein Kapazitätsproblem hin.

Wie viel Reserve sollte die Kommunikation besitzen?

Das System sollte nicht dauerhaft nahe seiner theoretischen maximalen Transaktionskapazität betrieben werden. Reserve wird für schwankende Antwortzeiten, Diagnosezugriffe und Wiederholungen benötigt.

Ist die maximale Gerätezahl eines Gateways gleichzeitig die maximale Zahl schnell pollbarer Geräte?

Nein. Teilnehmerzahl und erreichbare Aktualisierungsrate sind unterschiedliche Kenngrößen.

Was ist der IF2E011?

Der bei ICS Schneider angebotene IF2E011 ist ein Konverter für Ethernet-/RS485-Kommunikation mit TCP/IP-Anbindung.

Wie viele Geräte nennt ICS für den IF2E011?

Die ICS-Produktseite nennt bis zu 254 Geräte im Netzwerk je Konverter. Die tatsächlich realisierbare Pollingrate hängt jedoch von der gesamten Kommunikationsarchitektur ab.

Welche Versorgung benötigt der IF2E011?

ICS nennt für das Gerät eine Hilfsspannung von 80 … 270 VAC.

Wie breit ist der IF2E011?

ICS beschreibt das Gerät als kompakte 2-Modul-Ausführung für Schaltschrankanwendungen.

Wo finde ich den IF2E011 bei ICS Schneider?

Weitere Informationen finden Sie unter IF2E011 – Konverter Ethernet / RS485 bei ICS Schneider.

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

Eine Übersicht finden Sie unter IIoT-Lösungen bei ICS Schneider.