Industrielle Abfrage: Rückstau und Wiederholungen

Ein Modbus-RTU-Master sendet eine Anforderung, wartet auf Antwort oder Zeitüberschreitung und sendet erst dann die nächste. Ein RS-485-Bus hat daher eine Kapazitätsgrenze, die sich nicht durch eine Einstellung aufheben lässt. Ein Modbus-TCP-Gateway vor dem Bus schafft keine zusätzliche Kapazität. Fordert die Abfragesteuerung mehr an, wächst die Warteschlange, und der angezeigte Wert hinkt der Uhrzeit zunehmend hinterher. Zählen Sie die Transaktionen, bevor Sie Abfrageintervalle festlegen.

Dieser Leitfaden gehört zur Reihe über Datenqualität und Zustellung.

Transaktionen an der gemeinsamen Verbindung zählen

Zählen Sie am engsten Punkt. Zehn Modbus-TCP-Clients, die über ein serielles Gateway lesen, teilen sich dessen einzigen RS-485-Anschluss, unabhängig von der Geschwindigkeit der Ethernet-Seite. Das Gateway stellt ihre Anforderungen in eine Warteschlange und sendet sie nacheinander auf den Bus.

Beispiel für einen RS-485-Bus mit 9.600 bit/s, 8 Datenbits, gerader Parität und 1 Stoppbit:

Der Bus aktualisiert damit jeden Messpunkt etwa alle 3,4 s, nicht schneller. Ein Abfrageintervall von 1 s fordert die 3,4-fache Kapazität. Der folgende Modbus-RTU-Zeitbedarfsrechner verwendet dieselben Eingaben. Er zeigt 85 ms je Austausch und 0,68 s für je eine Anforderung an alle acht Zähler. Fünf Blöcke je Zähler ergeben 3,4 s.

Bei 11 Bits je Zeichen dauert ein Zeichen mit 9.600 bit/s 1,15 ms; die Pause von 3,5 Zeichen zwischen Frames dauert 4,0 ms. Oberhalb von 19.200 bit/s setzt der Leitfaden für serielle Leitungen die Frame-Pause auf 1,75 ms und die maximale Pause zwischen Zeichen auf 0,75 ms fest (Abschnitt 2.5.1.1). Eine höhere Baudrate verkürzt die Übertragungszeit, nicht aber die Antwortverzögerung des Geräts. Bei 38.400 bit/s dauert derselbe Austausch etwa 37 ms, davon 20 ms im Zähler.

Lesen Sie größere Blöcke. Jede Transaktion benötigt eine Anforderung, die Geräteverzögerung und eine Frame-Pause, unabhängig von der Zahl zurückgegebener Register. Bei 9.600 bit/s und 20 ms Geräteverzögerung dauern 20 Abfragen zu je zwei Registern etwa 870 ms. Eine Abfrage derselben 40 aufeinanderfolgenden Register dauert etwa 130 ms. Die Funktionscodes 03 und 04 lesen bis zu 125 Register in einer Anforderung (Modbus-Anwendungsprotokoll V1.1b3, Abschnitte 6.3 und 6.4). Enthält ein Block eine vom Gerät nicht implementierte Adresse, scheitert er mit Exception 02, Illegal Data Address. Fassen Sie nur Bereiche zusammen, die die Registertabelle als lesbar aufführt, und prüfen Sie, ob das Gerät eine niedrigere Grenze je Anforderung vorgibt.

Bei BACnet MS/TP zeigt sich dieselbe Begrenzung anders. Eine Steuerung sendet nur, während sie das Token besitzt; ein Router sendet dabei höchstens Max_Info_Frames Anforderungen pro Token-Besitz. Edge fragt BACnet über BACnet/IP ab und erreicht MS/TP-Steuerungen daher durch einen Router. Jede Abfrage wartet auf dessen nächste Sendemöglichkeit. Der Leitfaden BACnet/IP und MS/TP berechnet die Umlaufzeit des Tokens.

Was ein ausgefallenes Gerät kostet

Jede Anforderung an ein Gerät ohne Antwort wartet bis zum vollen Antwort-Timeout. Im Beispiel verlängert ein ausgefallener Zähler bei fünf Anforderungen pro Zyklus und 1 s Timeout jeden Zyklus um 5 s. Aus 3,4 s werden 8,0 s, und die sieben funktionsfähigen Zähler werden seltener als halb so oft gelesen.

Der Leitfaden für serielle Leitungen nennt bei 9.600 bit/s eine bis mehrere Sekunden als typischen Antwort-Timeout (Abschnitt 2.4.1). Für ein langsames Gerät ist das sicher, für einen ausgelasteten Bus teuer. Bestimmen Sie den Timeout stattdessen aus Messungen: Erfassen Sie an einem normalen Betriebstag die langsamste Antwort jedes Geräts und setzen Sie den Timeout auf etwa das Doppelte. Antwortet ein Zähler spätestens nach 150 ms, erhält er 300 ms Timeout. Der zusätzliche Zeitbedarf bei Ausfall sinkt im Beispiel von 5 auf 1,5 s.

Reduzieren Sie anschließend die Abfragerate je betroffenem Gerät. Beispiel: Nach drei aufeinanderfolgenden Timeouts wird das Gerät aus dem normalen Zeitplan genommen, seine Messpunkte werden als veraltet markiert. Senden Sie alle 60 s eine einzelne Testabfrage. Nach einer erfolgreichen Antwort kehrt das Gerät in den normalen Zeitplan zurück. Die gesunden Zähler erreichen wieder ihren 3,4-s-Zyklus; das ausgefallene Gerät kostet 0,3 s je Minute.

Der Bus braucht trotzdem Reserve für Timeouts, bevor diese Reduzierung einsetzt. Bei einem 5-s-Intervall hat der Bus im Beispiel 1,6 s frei. Ein ausgefallener Zähler mit 300 ms Timeout kostet 1,5 s und passt hinein. Mit 1 s Timeout kostet er 5 s und passt nicht. Reichen die freien Zeiten nicht einmal für die Timeouts eines Geräts, teilen Sie den Bus auf.

Wenn Anforderungen schneller eintreffen als sie abgearbeitet werden

Wird der Beispielbus jede Sekunde abgefragt, erzeugt die Abfragesteuerung 40 Anforderungen je Sekunde. Der Bus verarbeitet etwa zwölf. Die Warteschlange wächst damit um rund 28 Anforderungen je Sekunde. Bei Bearbeitung in Eingangsreihenfolge lag eine nach zehn Minuten gesendete Anforderung bereits etwa sieben Minuten in der Warteschlange. Alle Statusanzeigen können dabei grün bleiben: Der Bus arbeitet, die Geräte antworten, keine Anforderung scheitert. Nur die Zeitstempel zeigen, dass die Daten sieben Minuten alt sind.

Legen Sie fest, was mit überfälliger Arbeit geschieht:

Überwachen Sie neben der Länge auch das Alter der ältesten wartenden Anforderung. Auf einem Bus, der Schritt hält, wartet keine Anforderung länger als ein Abfrageintervall. Alarmieren Sie, wenn die älteste mehr als zwei Intervalle alt ist.

Aktuelle Zustandswerte von Energieregistern trennen

Die meisten Messpunkte brauchen nicht das kürzeste Intervall. Ein Energieregister (kWh) ist ein fortlaufender Zählerstand. Eine Abfrage alle 15 Minuten verliert keine Energie, denn der nächste Stand enthält alles seit der letzten Abfrage. Leistung, Sollwert oder Schalterstatus für eine Steuerung brauchen dagegen Sekundenintervalle.

Legen Sie die wenigen aktuellen Zustandswerte auf ein kurzes, Energie- und Konfigurationsregister auf ein längeres Intervall. Angenommen, jeder Zähler im Beispiel hat einen Block für aktuelle Werte alle 5 s und vier Energieblöcke alle 15 Minuten. Für die aktuellen Werte braucht der Bus 8 × 85 ms = 0,68 s je 5 s. Die 32 Energieabfragen brauchen einmal je Viertelstunde 2,7 s. Verteilen Sie sie über das Intervall, damit nicht alle zur Viertelstunde eintreffen und die aktuellen Abfragen 2,7 s blockieren.

Nur Fehler wiederholen, die sich beheben können

Hinter einem Modbus-TCP-Gateway liegen zwei Timeouts hintereinander: der des Clients und der serielle Timeout des Gateways. Setzen Sie den Client-Timeout höher als die Summe aus seriellem Timeout und Wartezeit in der Gateway-Warteschlange. Andernfalls gibt der Client eine noch laufende Anforderung auf, wiederholt sie und bringt eine zweite Kopie derselben Abfrage auf den Bus. Der Leitfaden Modbus TCP und RTU behandelt Gateway-Timeouts und Verbindungsgrenzen.

Ein Timeout beim Schreiben (Funktion 06 oder 16) belegt keinen fehlgeschlagenen Schreibzugriff. Das Gerät kann ihn ausgeführt haben, während die Antwort verloren ging. Lesen Sie das Register zurück, bevor Sie es erneut versuchen. Einen absoluten Sollwert zweimal zu schreiben ist unkritisch. Ein Schreibzugriff, der eine Aktion auslöst, etwa Zählerrücksetzung oder Startbefehl, kann zweimal wirken. Wiederholen Sie ihn daher niemals ohne vorheriges Zurücklesen.

Exponentielles Backoff mit zufälliger Verzögerung (Jitter) ist wichtig, wenn viele Clients denselben Server nutzen. Mehrere Modbus-TCP-Clients hinter einem Gateway oder eine Flotte von Standort-Gateways, die sich nach einem Ausfall neu verbindet, versuchen es sonst alle gleichzeitig. AWS beschreibt das Verfahren mit Grenzen für die Anzahl der Versuche und die längste Wartezeit. Ohne diese Streuung können die Wiederholungen eine langsame Verbindung auch nach Behebung des ursprünglichen Fehlers überlastet halten. Auf einem RS-485-Bus gibt es nur einen Master; dort bewirkt Jitter nichts. Die Reduzierung je Gerät ist entscheidend.

Wiederherstellung unter Last prüfen

1. Betreiben Sie die vollständige Messpunktliste mindestens eine Stunde lang mit den geplanten Intervallen. Erfassen Sie die Zykluszeit. Sie muss um mindestens die Timeouts eines Geräts kürzer als das schnellste Abfrageintervall sein.
2. Schalten Sie ein Gerät aus. Nach Beginn der reduzierten Abfrage müssen die Messwerte der anderen Geräte wieder jünger als zwei Intervalle sein.
3. Schalten Sie es wieder ein. Seine Werte müssen spätestens nach einer Testabfrageperiode wieder aktuell sein, im obigen Beispiel nach 60 s.
4. Unterbrechen Sie die Verbindung zur übergeordneten Plattform 30 Minuten lang. Lokale Messwerte müssen ihre normalen Zeitstempel behalten; die ausgehende Warteschlange muss erwartungsgemäß wachsen: Messpunkte je Minute × 30.
5. Stellen Sie die Verbindung wieder her. Jeder zwischengespeicherte Messwert muss einmal ankommen. Zählen Sie beim Empfänger die Messwerte je Messpunkt und Zeitstempel und prüfen Sie, ob die Bus-Zykluszeit innerhalb von zwei Zyklen wieder den Wert aus Schritt 1 erreicht.

Abfrage in Edge

Edge auf dem ZGW-20 Gateway hat fünf Modbus-Verbindungsslots. Jeder Slot verwaltet einen Endpunkt: einen seriellen Anschluss oder einen TCP-Host mit Port. Jeder hat eigene Warteschlangen, Ratenlimits, Latenzwerte und Fehler-Backoff sowie nach einem Schreibzugriff eine Pause von 2.000 ms bei Live-Abfragen. Alle Unit-IDs eines Slots teilen sich diese Ressourcen. Ein ausfallendes Gerät hinter einem Gateway kann daher die gesunden Geräte desselben Slots verzögern. Nutzen Sie je unabhängigem Endpunkt einen eigenen Slot.

Das Fehler-Backoff zählt aufeinanderfolgende fehlgeschlagene Anforderungen des Slots, nicht eines einzelnen Geräts. Nach drei Fehlern pausiert Edge die Abfrage für 5 s oder zwei Abfrageintervalle, je nachdem, was länger ist. Nach sechs Fehlern sind es 15 s oder drei Intervalle, nach zehn 30 s oder fünf Intervalle. Eine erfolgreiche Antwort setzt den Zähler zurück. Gesunde Geräte desselben Slots antworten meist zwischen Anforderungen an das ausgefallene Gerät. Die Folge erreicht dann selten drei Fehler, und die Timeouts des ausgefallenen Geräts belasten weiter jeden Zyklus. Deshalb ist der Timeout-Wert wichtig.

Standardmäßig sendet ein Slot höchstens 20 Live-Anforderungen und fünf geplante, uhrzeitsynchronisierte Anforderungen je Sekunde. Beide Grenzen lassen sich von 1 bis 100 einstellen. Der Live-Standardwert liegt über der Kapazität des Beispielbusses von etwa zwölf Anforderungen je Sekunde bei 9.600 bit/s; setzen Sie ihn unter die gemessene Kapazität. Die Warteschlange für geplante Abfragen hält 5.000 Anforderungen und verwirft die ältesten zuerst. Die Live-Warteschlange hält 250 und fasst gleiche Abfragen zusammen. Steigt die Slot-Latenz über 5.000 ms, begrenzt Edge die Live-Abfrage dort auf eine Anforderung je Sekunde. Edge fasst zusammenhängende Leseanforderungen zu Blöcken mit bis zu 125 Registern zusammen. Jeder Slot meldet letzte und mittlere Latenz sowie Fehlerzahl; verworfene geplante Abfragen erscheinen als Warnung im Log. Ein Gerät gilt erst nach zwei verpassten erwarteten Abfragen als offline, frühestens aber nach fünf Minuten.

Diese Grenzen schützen einen langsamen Bus; sie erhöhen seine Kapazität nicht. Eine ZMB Modbus Interface ist RS-485-Master auf einem eigenen kurzen Bus. Das ZMB-31 liest bis zu 30 Register am benachbarten Gerät und sendet die Werte über das Zigbee-Mesh an das Gateway. Mehrere ZMB ersetzen einen langen gemeinsamen Bus durch mehrere kurze Busse mit getrennten Timeout-Budgets.