Fehlerbehebung bei Durchflusszählern: Integer- vs. Real-Berechnungen in der SPS

Fehler bei Durchflusszählern in SPSen resultieren meist aus zwei mathematischen Problemen: Integer-Abschneidung (Truncation) und Genauigkeitsverlust bei Gleitkommazahlen einfacher Genauigkeit. INT-Tags verwerfen Bruchteile des Durchflusses, während 32-Bit-REAL-Tags bei großen akkumulierten Summen kleine Inkremente nicht mehr registrieren können. Eine zuverlässige Zählung erfordert Disziplin bei den Datentypen, ein durchdachtes Rollover-Design und eine simulationsbasierte Validierung.

Ein Durchflusszähler kann falsche Werte liefern, selbst wenn Messumformer, Pumpen und Rohrleitungen korrekt arbeiten. Der Fehler liegt oft im mathematischen Modell der SPS, nicht im Prozess. Diese Unterscheidung ist wichtig, da fehlerhafte Mathematik unauffälliger ist als defekte Hardware.

Während eines simulierten 24-Stunden-Pumpenlaufs in OLLA Lab, bei dem ein 16-Bit-INT-Zähler gegen wiederholte Inkremente von 0,4 Gallonen getestet wurde, verzeichnete der Akkumulator 0 Gallonen, während der simulierte Prozess 576 Gallonen bewegte. Methodik: Stichprobengröße = 1 kontrollierte Simulationsaufgabe mit wiederholten festen Inkrementen; Basis-Vergleichswert = erwartete arithmetische Akkumulation von 0,4 Gallonen über 1.440 Minuten; Zeitfenster = 24 simulierte Stunden. Dies stützt eine spezifische Erkenntnis: Integer-Abschneidung kann in einem deterministischen Testfall zum vollständigen Verlust von fraktioniertem Durchfluss führen. Es begründet keine universelle Feldausfallrate.

Hier wird der Unterschied zwischen „Syntax“ und „Einsatzfähigkeit“ deutlich. Ein Netzwerk kann korrekt aussehen, fehlerfrei kompilieren und dennoch den Betrieb über Wochen hinweg in die Irre führen.

Abschneidefehler (Truncation Errors) treten auf, wenn eine SPS fraktionierten Durchfluss mit einem Integer-Datentyp verarbeitet, der keine Dezimalstellen darstellen kann. Wenn das eingehende Inkrement 0,8 beträgt und das Ziel ein INT ist, wird der Nachkommaanteil verworfen, bevor er jemals in den Bestand einfließt.

In IEC 61131-3-Umgebungen ist dies ein normales Verhalten der Datentypen. Der Fehler besteht in der Annahme, der Prozess würde dies verzeihen.

Die Grenzen von 16-Bit-Integer-Werten mit Vorzeichen

Ein 16-Bit-Integer mit Vorzeichen (`INT`) hat einen begrenzten Bereich:

- Minimum: `-32.768` - Maximum: `32.767`

Wenn ein Zähler Impulszahlen oder skalierte Volumina direkt in einen `INT` akkumuliert, treten schnell zwei Fehlermodi auf:

- Überlauf: Sobald der Wert `32.767` überschreitet, springt er je nach Plattformverhalten und Befehlshandhabung in den negativen Bereich oder löst einen Fehler aus. - Löschung von Nachkommastellen: Jeder Wert unter 1,0 wird beim Casting oder Schreiben in ein Integer-Ziel abgeschnitten.

Bei Anwendungen mit Impulsen pro Einheit kann ein Überlauf überraschend schnell eintreten. Bei einem aus analogen Werten abgeleiteten inkrementellen Zähler kann die Abschneidung bei jedem Zyklus auftreten. Das eine ist dramatisch, das andere oft schwerer zu bemerken.

Warum Integer-Zähler stillschweigend realen Durchfluss löschen

Integer-Mathematik „rundet nicht ein wenig“. Sie entfernt den Rest. Wenn Ihre Logik berechnet:

• `Durchfluss_Inkrement = 0,8 Gallonen pro Zyklus`
• `Gesamt_INT = Gesamt_INT + Durchfluss_Inkrement`

dann wird die effektive Addition zu:

• `Gesamt_INT = Gesamt_INT + 0`

Der Prozess hat Flüssigkeit bewegt. Die SPS hat nichts aufgezeichnet.

Dies ist ein häufiger Designfehler, wenn Ingenieure ein 4–20-mA-Durchflusssignal in technische Einheiten skalieren, durch eine Zeitbasis teilen und das Ergebnis dann in einen Integer-Akkumulator schreiben. Das Netzwerk mag syntaktisch korrekt sein, aber der Zähler ist bereits kompromittiert.

Warum die Zykluszeit das Problem verschärft

Schnelle Zykluszeiten erhöhen die Wahrscheinlichkeit, dass jedes inkrementelle Volumen klein ist. Das bedeutet, dass mehr Additionen unter 1,0 technische Einheiten fallen und verloren gehen, wenn das Ziel auf Integer-Basis arbeitet.

Ein hochauflösender Zähler erfordert daher mehr als nur einen ADD-Baustein. Er erfordert eine Abstimmung zwischen:

• Signalskalierung,
• Zykluszeit,
• technischen Einheiten,
• Datentyp des Akkumulators.

Ein 32-Bit-REAL löst das Problem der Nachkommastellen, führt aber einen anderen Fehler ein: Genauigkeitsverlust bei großen akkumulierten Werten. Sobald die Summe groß genug wird, verändern kleine eingehende Inkremente den gespeicherten Wert nicht mehr.

Dies ist ein Verhalten gemäß IEEE 754 und nicht zwangsläufig ein Softwarefehler. So funktioniert Gleitkommaarithmetik mit einfacher Genauigkeit.

Die Grenze der Gleitkomma-Genauigkeit

Die meisten `REAL`-Typen in SPSen sind IEEE 754 Gleitkommazahlen mit einfacher Genauigkeit. In der Praxis bieten sie etwa 7 signifikante Dezimalstellen an Genauigkeit.

Das bedeutet, dass die Größe der kleinsten darstellbaren Änderung von der Größenordnung der bereits gespeicherten Zahl abhängt.

Beispiele:

• Nahe `10,0` ist die Addition von `0,01` meist darstellbar.
• Nahe `1.000.000,0` ist `0,01` möglicherweise zu klein, um den gespeicherten Wert zu ändern.
• Bei noch größeren Summen können selbst moderate Inkremente „verschluckt“ werden.

Der Zähler fällt nicht aus, weil der Prozess gestoppt hat. Er fällt aus, weil die numerische Auflösung des Akkumulators gröber geworden ist als das hinzugefügte Inkrement.

Wie der „Verschluckungs-Effekt“ aussieht

Das klassische Symptom ist einfach:

• der Durchflussmesser zeigt aktiven Durchfluss an,
• die Pumpe läuft,
• der Prozess bewegt physisch Produkt,
• aber der SCADA-Zähler stagniert.

An diesem Punkt vermuten Bediener oft Kommunikationsprobleme, Verzögerungen im Historian oder eine Drift der Instrumentierung. Manchmal ist das Problem viel banaler: Der Akkumulator hat seine nützliche Granularität verloren.

Ein `REAL` kann große Zahlen oder kleine Inkremente für viele Aufgaben ausreichend gut darstellen. Er kann jedoch beides nicht unbegrenzt in einem wachsenden Zähler ohne Designkontrollen leisten.

Warum dies bei Chargenprozessen, Versorgungsbetrieben und Berichten wichtig ist

Nicht jeder Zähler ist finanziell kritisch, aber viele sind betrieblich von Bedeutung. Fehler bei der Durchflussakkumulation können folgende Bereiche verfälschen:

• Berechnungen der Chargenausbeute,
• Aufzeichnungen zur Chemikaliendosierung,
• Wasserbilanzberichte,
• Schätzungen zum CIP-Verbrauch,
• Bestandsabgleiche von Tanks,
• Wartungsentscheidungen basierend auf dem Durchsatz.

Dieser Artikel erhebt keinen Anspruch auf Konformität mit eichpflichtigem Verkehr. Er stellt eine engere technische Behauptung auf: Wenn die Architektur des Akkumulators schwach ist, kann das gemeldete Volumen materiell von der physischen Realität abweichen.

Die richtige Antwort hängt davon ab, was Sie akkumulieren: Impulse, skalierte technische Einheiten oder fraktionierte Zeit-Inkremente. Es gibt keine universelle Wahl für den Tag, aber es gibt bewährte Muster.

Verwenden Sie DINT für Ganzzahl-Akkumulation, wo möglich

Wenn die Quelle ein Impulsstrom ist und jeder Impuls eine feste Menge darstellt, ist ein `DINT` meist sicherer als ein `INT`.

Warum:

• Ein 32-Bit-`DINT` mit Vorzeichen reicht von `-2.147.483.648` bis `2.147.483.647`.
• Er verzögert den Überlauf im Vergleich zu `INT` drastisch.
• Er bewahrt exakte Ganzzahl-Zählungen.

Für die Impulszählung ist das Zählen von Integern als Integer meist das sauberste Design.

Verwenden Sie REAL vorsichtig für fraktionierte Arbeitsakkumulation

Wenn das Quellinkrement fraktioniert ist, kann ein `REAL` als Arbeitsakkumulator nützlich sein, nicht immer als einziger Langzeitzähler.

Gute Anwendungsfälle:

• Akkumulation von fraktioniertem Durchfluss über kurze Zeitfenster,
• Zwischenspeicherung eines Teilbetrags vor einem Rollover,
• Unterstützung von für Bediener sichtbaren Tages- oder Chargensummen mit begrenzten Reset-Intervallen.

Riskanter Anwendungsfall:

• Ein einzelner 32-Bit-REAL wächst unbegrenzt, während sehr kleine Inkremente addiert werden.

Hier wird die Genauigkeitserosion zu einem Designproblem statt zu einem theoretischen.

Verwenden Sie LREAL, wenn Ihre Plattform dies unterstützt

Ein 64-Bit-`LREAL` bietet eine weitaus höhere Genauigkeit und einen größeren Bereich als ein 32-Bit-`REAL`. Auf Plattformen, die dies über Controller-, HMI-, Historian- und Schnittstellenebenen hinweg zuverlässig unterstützen, ist es oft die sauberere Lösung für langlebige fraktionierte Zählungen.

Aber „unterstützt“ muss eine durchgängige Unterstützung bedeuten:

• Verhalten der Controller-Befehle,
• Tag-Transport,
• SCADA/HMI-Kompatibilität,
• Speichertyp des Historian,
• Interpretation durch die Berichtsebene.

Ein mathematisch solider Controller-Tag reicht nicht aus, wenn der Rest des Stacks ihn stillschweigend auf einen kleineren Typ reduziert.

Ein kaskadierter Rollover-Zähler trennt die fraktionierte Akkumulation von der Langzeitspeicherung. Dieses Muster ist oft robuster als ein einzelner, ständig wachsender Gleitkomma-Zähler.

Das Designprinzip ist einfach:

• Akkumulieren Sie kleine Inkremente in einem Register, das Brüche verarbeiten kann,
• übertragen Sie größere Blöcke in einen langreichweitigen Integer-Zähler,
• behalten Sie nur den Rest im fraktionierten Register.

Dies reduziert das Risiko, dass winzige Additionen bei einer sehr großen Gleitkommazahl verschwinden.

Beispiel-Logikmuster

Schritt 1: Akkumulieren Sie das Durchflussinkrement in einem REAL-Arbeitszähler.

`ADD Durchfluss_Inkrement, Arbeits_Summe_Real, Arbeits_Summe_Real`

Schritt 2: Prüfen Sie, ob der Arbeitszähler einen Übertragungsschwellenwert erreicht hat.

`CMP Arbeits_Summe_Real >= 100.0`

Schritt 3: Verschieben Sie den Schwellenwertbetrag in einen langreichweitigen Integer-Master-Zähler.

`ADD 100, Master_Summe_DINT, Master_Summe_DINT`

`SUB Arbeits_Summe_Real, 100.0, Arbeits_Summe_Real`

Warum dieses Muster funktioniert

Der technische Vorteil ist die numerische Stabilität.

Ein kaskadiertes Design bietet:

• Erhalt von Nachkommastellen im Arbeitsregister,
• Langzeitspeicherung im Integer-Master-Zähler,
• reduzierten Genauigkeitsverlust, da der REAL-Teilzähler relativ klein bleibt,
• klare Auditierbarkeit, wie die Summe gebildet wird.

Sie können das Muster erweitern mit:

• Chargensummen,
• täglichen Reset-Registern,
• nichtflüchtigen, remanenten Summen,
• Alarmprüfungen auf Rollover-Anomalien,
• Sequenzverriegelungen, die Aktualisierungen bei ungültigen Instrumentenzuständen verhindern.

Was „korrekt“ für ein Zählerdesign bedeutet

Ein Zähler ist nicht „korrekt“, weil das Netzwerk kompiliert oder sich die Zahl im HMI ändert. Er ist korrekt, wenn die Logik eine betriebliche Definition erfüllt, wie zum Beispiel:

• die akkumulierte Menge entspricht der erwarteten Arithmetik innerhalb der definierten Toleranz,
• Überlaufverhalten wird verhindert oder explizit gehandhabt,
• ungültige Eingangszustände erzeugen keine falsche Akkumulation,
• das Reset-Verhalten ist kontrolliert und auditierbar,
• die Langzeitgenauigkeit bleibt für den Berichtszweck geeignet.

Das ist der Standard, der bei der Inbetriebnahme zählt.

OLLA Lab ist hier als begrenzte Validierungsumgebung nützlich, nicht als Orakel. Der Wert liegt darin, dass Ingenieure das Verhalten Zyklus für Zyklus beobachten, Eingaben sicher manipulieren und den Zustand der Logik gegen das simulierte Prozessverhalten vergleichen können, bevor ein Live-System den Fehler übernimmt.

In der Praxis bedeutet das, dass Sie testen können, ob die Zählermathematik unter realistischen Betriebsbedingungen korrekt funktioniert, anstatt einem visuell sauberen Netzwerk zu vertrauen.

Was OLLA Lab beobachtbar macht

Mit dem Ladder Logic Editor, dem Simulationsmodus und dem Variablen-Panel kann ein Benutzer:

• einen Zähler mit `INT`, `DINT`, `REAL` oder gemischter Logik aufbauen,
• feste oder variierende Durchflussinkremente injizieren,
• Akkumulatorwerte in Echtzeit überwachen,
• das Eingangsverhalten gegen die Ausgangsmathematik vergleichen,
• die Simulation beschleunigen, um Langzeit-Genauigkeitsprobleme schneller aufzudecken.

Das ist betrieblich nützlich, da viele dieser Fehler im Feld nur langsam auftreten. In der Simulation werden sie prüfbar.

Betriebliche Definition von „Simulation-Ready“

In diesem Kontext bedeutet Simulation-Ready, dass ein Ingenieur:

• das beabsichtigte Steuerungsverhalten beweisen kann,
• die Auswirkung jedes Eingangs- und Zustandsübergangs beobachten kann,
• numerische und sequenzielle Fehler diagnostizieren kann,
• die Logik gegen realistisches Prozessverhalten absichern kann,
• dokumentieren kann, warum die überarbeitete Logik zuverlässiger ist, bevor sie einen Live-Prozess erreicht.

Dies bedeutet nicht Standortkompetenz, Zertifizierung oder automatische Einsatzbereitschaft für eine unbeaufsichtigte Inbetriebnahme. Simulation ist eine Probe, keine rechtliche Absolution.

Ein praktischer OLLA Lab Validierungs-Workflow

Eine nützliche Validierungssequenz in OLLA Lab wäre:

1. Erstellen Sie eine simulierte Durchflussquelle mit bekanntem inkrementellem Verhalten.
2. Bauen Sie einen Zähler mit `INT` und einen weiteren mit `REAL`.
3. Lassen Sie beide unter identischen Inkrementen laufen.
4. Beobachten Sie die Abschneidung im Integer-Pfad.
5. Erhöhen Sie den REAL-Akkumulator, bis kleine Inkremente den Gesamtwert nicht mehr verändern.
6. Ersetzen Sie das Design durch ein kaskadiertes Rollover- oder höherpräzises Verfahren.
7. Führen Sie das Szenario erneut aus und vergleichen Sie die Ergebnisse.

Hier wird OLLA Lab betrieblich nützlich. Es bietet Einblick in eine Klasse von Fehlern, die oft die Schreibtischprüfung überleben und erst offensichtlich werden, wenn der Bestandsabgleich schwierig wird.

Ein Screenshot eines Netzwerks ist kein technischer Nachweis. Er ist nur illustrativ, sofern er nicht mit Verhalten, Fehlerinjektion und Revisionshistorie verknüpft ist.

Wenn Sie ernsthafte Steuerungsarbeit demonstrieren wollen, verwenden Sie ein kompaktes Nachweispaket mit sechs Teilen:

Dokumentieren Sie den exakten Fehler: Integer-Abschneidung, Überlauf, Verschlucken bei Gleitkommazahlen, falsche Skalierung oder Race-Conditions beim Reset.

Erklären Sie die Designänderung: Migration auf `DINT`, Einführung von `LREAL`, kaskadierter Rollover, Schwellenwert-Transferlogik oder gegatete Akkumulation.

1. Systembeschreibung Definieren Sie den Prozesskontext, die Signalquelle, Einheiten, Annahmen zur Zykluszeit und das Ziel der Zählung.
2. Betriebliche Definition von „korrekt“ Geben Sie das erwartete arithmetische Verhalten, die Toleranz, Reset-Regeln und den Umgang mit ungültigen Zuständen an.
3. Ladder-Logik und simulierter Anlagenzustand Zeigen Sie die Logik und das entsprechende simulierte Prozessverhalten zusammen, nicht isoliert.
4. Der injizierte Fehlerfall
5. Die vorgenommene Revision
6. Erkenntnisse Halten Sie fest, was der Test bewiesen hat, welche Annahmen fehlgeschlagen sind und was zum Designstandard werden sollte.

Diese Struktur kommt einem Inbetriebnahmenachweis näher als einem einfachen Portfolio-Schnappschuss.

Das zugrunde liegende Verhalten der Datentypen basiert auf standardmäßigen industriellen Programmier- und numerischen Berechnungsprinzipien, nicht auf Plattform-Folklore.

Relevante Ankerpunkte sind:

• IEC 61131-3 für SPS-Programmiersprachen und Konventionen zu Datentypen in industriellen Steuerungssystemen.
• IEEE 754 für das Verhalten der Gleitkommaarithmetik, einschließlich endlicher Genauigkeit und Darstellungsgrenzen.
• IEC 61508 für das breitere Prinzip, dass systematische Designfehler in programmierbaren Systemen durch disziplinierte Ingenieursprozesse identifiziert und kontrolliert werden sollten.
• Literatur zu Simulation und Digitalen Zwillingen in der industriellen Automatisierung, die generell den Einsatz modellierter Umgebungen zur Validierung des Steuerungsverhaltens vor dem Einsatz unterstützt, insbesondere wenn Live-Tests kostspielig oder riskant sind.

Dieser Artikel behauptet nicht, dass ein Simulator allein Konformität, Sicherheitsintegrität oder Feldakzeptanz begründet. Er stellt eine engere Behauptung auf: Simulation verbessert die Beobachtbarkeit deterministischer Logikfehler, die andernfalls teuer zu spät erkannt werden.

Fehler bei Durchflusszählern werden oft durch schlechte Wahl der Datentypen verursacht. `INT`-Tags löschen Nachkommastellen, `REAL`-Tags können bei großen Summen kleine Inkremente verlieren, und beide Fehler können lange genug unsichtbar bleiben, um Berichte, das Vertrauen in den Bestand und das Vertrauen der Bediener zu beschädigen.

Die technische Lösung ist im Prinzip einfach: Verwenden Sie die richtige numerische Architektur für das Signal, definieren Sie vor der Inbetriebnahme, was „korrekt“ bedeutet, und validieren Sie das Verhalten unter Last. Das ist der Unterschied zwischen einem Ladder-Programm, das läuft, und einer Steuerungsstrategie, die in der Produktion zuverlässig bleibt.

- IEEE Std 754-2019 — Floating-Point Arithmetic - IEC 61131-3 — PLC programming languages - IEC 61508 Functional Safety overview - Kritzinger et al. (2018), Digital twin in manufacturing (IFAC) - Tao et al. (2019), Digital twin in industry (IEEE TII)