Implementierung einer 3-Sigma-Fehlererkennung für Pumpen in Kontaktplan-Logik

Die 3-Sigma-Pumpenfehlererkennung nutzt gleitende Statistiken innerhalb der SPS, um ein abnormales analoges Verhalten zu identifizieren, bevor ein fester Alarmschwellenwert überschritten wird. Durch die Berechnung eines gleitenden Mittelwerts und der Standardabweichung aus aktuellen Druckmesswerten kann die Kontaktplan-Logik bei varianzbasierten Anomalien wie Kavitation, Leckagen oder instabilen Strömungsbedingungen auslösen.

Statische Unterdruck-Alarme sind eine späte Verteidigungslinie, kein Frühwarnsystem. Bis der Ausgangsdruck endlich unter einen festen Auslösepunkt fällt, läuft die Pumpe möglicherweise bereits unter Kavitation, Dichtungsverschleiß oder Strömungsinstabilität, die im Signal bereits seit mehreren Sekunden sichtbar war.

Während der Validierung eines Kreiselpumpenszenarios in OLLA Lab erkannte ein 3-Sigma-Varianzschwellenwert auf einem simulierten 4–20 mA-Ausgangsdrucksignal Anomalien durch Strömungsverlust 4,2 Sekunden schneller als ein herkömmlicher statischer Unterdruck-Alarm und löste eine sichere Abschaltung aus, bevor ein simulierter Dichtungsschaden auftrat [Methodik: n=24 simulierte Fehlerläufe in einem Kreiselpumpenszenario; Basis-Vergleichswert = nur fester Unterdruck-Auslöser; Zeitfenster = Anomaliebeginn bis Alarmausgabe über ein 100-ms-Abtastregime]. Dies ist ein interner Benchmark von Ampergon Vallis und kein allgemeiner Leistungsanspruch der Industrie.

Der technische Kernpunkt ist einfach: Cloud-Analysen sind nützlich für die Trendüberprüfung, aber deterministische Verriegelungen gehören an den Control Edge. Wenn die Logik sofort reagieren muss, sollte die SPS nicht auf einen Historian, ein Dashboard oder ein Netzwerk warten, das möglicherweise nicht verfügbar ist.

Statistische Prozesskontrolle (SPC) auf SPS-Ebene ist wertvoll, da sie Anomalieerkennung mit deterministischem Handeln kombiniert. Der Unterschied ist entscheidend: Analysen können einen Fehler nachträglich erklären, aber Verriegelungen müssen Schäden in Echtzeit verhindern.

Drei praktische Vorteile rechtfertigen den Betrieb einer begrenzten SPC-Logik in der SPS:

1. Deterministische Verriegelung Die SPS kann einen Alarm ausgeben, einen Motor stoppen oder einen Neustart innerhalb des normalen Zyklus von Abtastung und Ausgabe unterbinden. Das unterscheidet sich wesentlich vom Warten auf eine cloudseitige Auswertung und Rückmeldung.
2. Netzwerkresilienz Die Schutzlogik bleibt aktiv, selbst wenn die IT/OT-Verbindung unterbrochen ist, der Broker stockt oder der Historian das Signal in eine für die schnelle Fehlererkennung weniger nützliche Form komprimiert.
3. Sichtbarkeit hochfrequenter Signale Die SPS sieht den analogen Eingang im Takt der Steuerungsaufgabe. Ein Historian tut dies oft nicht. Schnelles Flattern, intermittierende Instabilität und kurzzeitige Ausschläge sind genau die Verhaltensweisen, die bei festen Schwellenwerten zuerst übersehen werden.

Das bedeutet nicht, dass jede prädiktive Wartungsfunktion in die Kontaktplan-Logik gehört. Langfristige Diagnosen, Flottenanalysen und modellbasierte Wartungsplanung werden üblicherweise besser vorgelagert behandelt. Die SPS ist der richtige Ort für begrenzte, deterministische statistische Logik, die den Maschinenzustand unmittelbar beeinflussen muss.

Aus Sicht der Normen entspricht diese Trennung der Disziplin der funktionalen Zuordnung in industriellen Steuerungssystemen: Schutzmaßnahmen sollten deterministisch und testbar bleiben, während beratende Analysen an anderer Stelle angesiedelt sein können (IEC, 2010; IEC, 2016). Unterschiedliche Ebenen haben unterschiedliche Verpflichtungen.

Die 3-Sigma-Logik ist eine gleitende Standardabweichung, die auf einen Live-Prozesstag angewendet wird. Die Formel ist bekannt; die Implementierungsdetails sind der Punkt, an dem SPS-Projekte aufwendig werden.

Für ein Abtastfenster von N Druckmesswerten:

μ = (1/N) × Σxᵢ

• Mittelwert

σ² = (1/N) × Σ(xᵢ - μ)²

• Varianz

σ = √σ²

• Standardabweichung

UCL = μ + 3σ LCL = μ - 3σ

• 3-Sigma-Kontrollgrenzen

Wenn der aktuelle Druckwert außerhalb dieses Bandes liegt, setzt die Logik ein Bit für statistische Anomalien.

Erforderliche mathematische Bausteine im Kontaktplan

Eine praktische Implementierung erfordert in der Regel diese Anweisungstypen:

• FIFO / FFL / Array-Shift-Logik, um ein gleitendes Abtastfenster zu verwalten
• AVE oder explizite ADD/DIV-Logik zur Berechnung des gleitenden Mittelwerts
• SUB, um die Abweichung vom Mittelwert zu berechnen
• MUL, um die Abweichung zu quadrieren
• ADD, um quadrierte Abweichungen zu akkumulieren
• DIV, um die Varianz zu berechnen
• SQRT, um die Standardabweichung zu berechnen
• MUL erneut, um das 3-Sigma-Band zu erzeugen
• CMP / LIM / GRT / LES, um den Anomaliezustand auszulösen

Die zugrunde liegende Annahme ist, dass das Rauschen des Basissignals annähernd stabil und ausreichend gutartig ist, damit ein Standardabweichungsband sinnvoll ist. Echte Pumpensignale sind keine lehrbuchmäßigen Normalverteilungen, und kein kompetenter Ingenieur sollte etwas anderes behaupten. Aber für eine begrenzte Anomalieerkennung in einem stabilen Betriebsbereich ist die 3-Sigma-Logik oft nützlich, da sie einfach, transparent und testbar ist.

Ein gleitender Durchschnitt beginnt mit disziplinierter Abtastung und korrekten Datentypen. Wenn das analoge Drucksignal als Ganzzahl gespeichert und dann so dividiert wird, als wäre Präzision optional, wird die Mathematik irreführend sein.

### Schritt 1: Analogen Eingang in festem Intervall abtasten

Verwenden Sie einen Timer oder eine periodische Aufgabe, um den Druckeingang mit einer konstanten Rate abzutasten. Ein üblicher Ausgangspunkt ist:

- Abtastintervall: 100 ms - Fenstergröße: 50 Abtastwerte - Beobachtungsfenster: 5 Sekunden

Dies bietet genügend aktuelle Historie, um Instabilität zu erkennen, ohne das Kontrollband zu träge zu machen.

### Schritt 2: Abtastwerte in einem REAL-Array speichern

Verwenden Sie REAL-Datentypen für:

• aktuellen Druck
• Array-Elemente
• gleitenden Mittelwert
• Varianz
• Standardabweichung
• obere und untere Kontrollgrenzen

Dies vermeidet Rundungsfehler bei der Division und bewahrt die analoge Auflösung. Statistische Logik, die auf Ganzzahl-Mathematik basiert, ist oft eine stille Quelle für Fehlentscheidungen.

### Schritt 3: Das gleitende Fenster verwalten

Implementieren Sie eine FIFO- oder eine äquivalente Array-Shift-Routine, sodass jeder neue Abtastwert in das Fenster eintritt und der älteste Abtastwert verworfen wird. Die wichtigsten Kontrollen sind:

• Anzahl gültiger Abtastwerte
• Array-Grenzen
• Initialisierungszustand
• Verhalten, bevor das Array vollständig gefüllt ist

Berechnen Sie die Varianz nicht auf einem leeren oder teilweise undefinierten Puffer, es sei denn, die Logik behandelt diesen Zustand explizit. Division-durch-Null-Fehler sind kein Beweis für fortgeschrittene Analytik.

### Schritt 4: Den gleitenden Mittelwert berechnen

Sobald das Array gefüllt ist:

• summieren Sie alle Abtastwerte
• dividieren Sie durch die Anzahl der gültigen Abtastwerte
• speichern Sie das Ergebnis als `Rolling_Mean`

Wenn Ihre Plattform eine Durchschnitts-Anweisung unterstützt, verwenden Sie diese. Wenn nicht, ist eine explizite Summierung in Ordnung, sofern die Ausführungszeit für den Aufgabenzyklus akzeptabel ist.

Praktische Implementierungshinweise

Ein robuster Satz an Kontaktplan-Sprossen enthält normalerweise:

• ein Data_Ready-Bit, sobald das Abtastfenster voll ist
• eine Stats_Enable-Freigabe, die an den Pumpenlaufzustand gekoppelt ist
• eine Bad_Input_Quality-Sperre, falls das analoge Signal ungültig, außerhalb des Bereichs oder veraltet ist
• einen Startup_Mask_Timer, um Fehlalarme während Transienten zu verhindern

Hier ist das Urteilsvermögen bei der Inbetriebnahme gefragt. Eine Pumpe, die startet, stoppt oder den Betriebsmodus wechselt, ist für sich genommen statistisch nicht anomal; sie ändert lediglich ihren Zustand. Die Logik sollte den Unterschied kennen.

Wo OLLA Lab operativ nützlich wird

OLLA Lab bietet eine begrenzte Umgebung, um diese Array-Logik zu testen, bevor sie eine Live-Steuerung erreicht. Im browserbasierten Kontaktplan-Editor können Ingenieure die FIFO-Struktur aufbauen, die Logik im Simulationsmodus ausführen und das Variablen-Panel nutzen, um die Array-Füllung in Echtzeit zu beobachten.

Das ist wichtig, weil „simulationsbereit“ etwas Beobachtbares bedeuten sollte. Operativ bedeutet es, dass ein Ingenieur Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor sie einen echten Prozess erreicht. Die Syntax ist nur ein Teil davon. Die Bereitstellbarkeit ist der schwierigere Teil.

Die Sequenz der Standardabweichungs-Sprossen sollte explizit, begrenzt und leicht zu testen sein. Wenn die Logik zu clever für eine Überprüfung ist, ist sie zu clever, um ihr zu vertrauen.

Schritt-für-Schritt-Sequenz im Kontaktplan

Nachdem der gleitende Mittelwert berechnet wurde:

1. Iterieren Sie durch jeden Abtastwert im Array.
2. Subtrahieren Sie den Mittelwert vom Abtastwert.
3. Quadrieren Sie die Abweichung.
4. Akkumulieren Sie die quadrierten Abweichungen.
5. Dividieren Sie durch N, um die Varianz zu erhalten.
6. Wenden Sie SQRT an, um die Standardabweichung zu erhalten.
7. Multiplizieren Sie die Standardabweichung mit 3.0.
8. Addieren und subtrahieren Sie diesen Wert vom Mittelwert, um obere und untere Kontrollgrenzen zu erstellen.
9. Vergleichen Sie den aktuellen Druck mit diesen Grenzen.
10. Setzen Sie einen Alarm für statistische Anomalien, wenn das Signal außerhalb des Bandes liegt.

Beispiel für Kontaktplan-Logik

// 3-Sigma-Band berechnen MUL Standard_Deviation 3.0 Sigma_Band ADD Rolling_Mean Sigma_Band Upper_Control_Limit SUB Rolling_Mean Sigma_Band Lower_Control_Limit

// Anomalie-Alarm auslösen GRT Current_Pressure Upper_Control_Limit OTL Pump_Stat_Anomaly LES Current_Pressure Lower_Control_Limit OTL Pump_Stat_Anomaly

Überlegungen zum Verriegelungsdesign

Eine brauchbare Verriegelung benötigt meist mehr als eine einzelne Vergleichsanweisung. Erwägen Sie das Hinzufügen von:

• Persistenz-Timing, damit ein einzelner verrauschter Abtastwert die Pumpe nicht abschaltet
• Trennung von Alarm und Auslösung
• Sperre der automatischen Rücksetzung bis zur Überprüfung durch den Bediener
• Modus-basierte Freigaben, damit Wartungs- oder Handbetrieb keine Fehlauslösungen verursachen
• Ereignisprotokollierung für Mittelwert, Sigma, aktuellen Wert und Betriebszustand zum Zeitpunkt der Auslösung

Ein sauberes Muster ist:

• erster Verstoß → Stat_Alarm setzen
• anhaltender Verstoß für definierte Zeit → Trip_Request setzen
• bestätigter Stopp → Pump_Faulted verriegeln

Diese Sequenz ist einfacher zu beheben als eine einzelne Sprosse, die alles schlecht macht.

Eine Korrektur, die sich lohnt

Die 3-Sigma-Logik ist kein Ersatz für Prozessgrenzwerte. Sie ergänzt sie. Sie benötigen weiterhin harte Unterdruck-, Trockenlauf-, Überlast- und Freigabelogik. Die statistische Erkennung fängt abnormales Verhalten frühzeitig ab; feste Schutzgrenzwerte sichern weiterhin den Rand des sicheren Betriebs.

Varianzlogik erkennt Instabilität vor dem Zusammenbruch des Absolutwerts. Das ist der Hauptvorteil.

Eine kleine Dichtungsleckage, ein Saugproblem oder ein frühes Kavitationsereignis können Folgendes erzeugen:

• Druckflattern
• Zunahme der Schwingungsamplitude
• intermittierende Einbrüche und Erholungen
• instabiles Strömungsverhalten um einen ansonsten akzeptablen Mittelwert

Ein fester Alarm wie „Auslösen, wenn Druck < 50 PSI“ ignoriert all das, bis das Signal endlich die Linie kreuzt. Bis dahin kann sich der mechanische Zustand bereits verschlechtern.

Ein 3-Sigma-Band reagiert auf das Verhalten des Signals relativ zu seiner jüngsten Basislinie. Wenn die Pumpe normalerweise bei 72 PSI mit geringer Streuung läuft und plötzlich beginnt, zwischen 66 und 78 PSI zu oszillieren, steigt die Standardabweichung, selbst wenn der Mittelwert über dem statischen Auslösepunkt bleibt. Das ist oft die erste nützliche Warnung.

Dies ist keine Magie und nicht universell. Wenn der Prozess selbst von Natur aus instabil ist, sagt Ihnen ein Varianzalarm möglicherweise nur, dass der Prozess variabel ist. Die Methode funktioniert am besten, wenn sie auf einen stabilen Betriebsbereich mit bekanntem Normalverhalten, korrekter Modus-Gating und einem validierten Abtastfenster angewendet wird.

Forschung zur Zustandsüberwachung und Anomalieerkennung stützt den Wert varianzsensitiver Merkmale für rotierende Geräte und Prozesssysteme, insbesondere in Kombination mit domänenspezifischen Schwellenwerten und Betriebskontext (Jardine et al., 2006; Lei et al., 2020; Yin et al., 2014). Die Implementierung in einer SPS ist einfacher als viele modellbasierte Ansätze, aber die Anforderung an die technische Disziplin verschwindet nicht.

Das Abtastfenster sollte der Prozessdynamik entsprechen, nicht der Geduld des Ingenieurs. Ein 50-Abtastwerte-Fenster bei 100 ms kann für eine Pumpe angemessen und für eine andere ineffektiv sein.

Faktoren für die Fensterauswahl

Wählen Sie das gleitende Fenster basierend auf:

• Sensor-Reaktionszeit
• Pumpen- und Rohrleitungsdynamik
• erwarteter Störfrequenz
• Scanzeit und Steuerungsauslastung
• Toleranz gegenüber Fehlalarmen
• erforderlicher Reaktionsgeschwindigkeit

Ein kurzes Fenster reagiert schneller, ist aber verrauschter. Ein langes Fenster ist glatter, aber langsamer. Die richtige Antwort findet man meist durch das Testen von Fehlerfällen, nicht durch das Streiten über runde Zahlen.

Überlegungen zu Scan und Ausführung

Statistische Logik verbraucht Ressourcen der Steuerung. In einem sequentiellen SPS-Scan können wiederholte Array-Mathematik und Fließkommaoperationen teuer werden, insbesondere auf kleineren CPUs oder überlasteten Aufgaben.

Achten Sie auf:

• Anstieg der Scanzeit
• Überläufe periodischer Aufgaben
• Array-Indexfehler
• Division-durch-Null-Bedingungen
• nicht initialisierte REAL-Werte
• übermäßige Neuberechnungsfrequenz

Ein sinnvolles Muster ist:

• Abtastung in einem festen Intervall
• Berechnung der Statistik nur, wenn ein neuer Abtastwert eintrifft
• Trennung von hochpriorisierten Verriegelungen von Analysen mit niedrigerer Priorität
• Benchmarking der Scan-Auswirkung während der Validierung

Dies ist ein Grund, warum Simulation wichtig ist. Es ist billiger, in einer virtuellen Umgebung festzustellen, dass eine mathematische Routine zu rechenintensiv ist, als während der Inbetriebnahme, wenn der Betrieb wartet.

Alarm-Persistenz

Verwenden Sie einen Persistenz-Timer oder eine zählerbasierte Bestätigung vor dem Auslösen. Übliche Muster sind:

• Anomalie vorhanden für 500 ms
• 3 von 5 aufeinanderfolgenden Abtastwerten außerhalb des Bandes
• wiederholte Verstöße innerhalb eines gleitenden Zeitfensters

Das reduziert Fehlauslösungen bei gleichzeitiger Wahrung der Früherkennung. Der genaue Wert sollte gegenüber dem Prozessrisiko und der Pumpenanfälligkeit gerechtfertigt sein, nicht ohne Validierung kopiert werden.

Varianzlogik muss gegen dynamische Störungen getestet werden, nicht gegen statische Vorgaben. Ein erzwungener konstanter Wert beweist wenig mehr als die Tatsache, dass der Simulator eine Zahl halten kann.

In OLLA Lab können Ingenieure diese Logik in einer webbasierten Probenumgebung validieren, die Kontaktplan-Ausführung, Live-Variableninspektion und simuliertes Geräteverhalten kombiniert. Der relevante Arbeitsablauf ist begrenzt und praktisch:

• Aufbau der Kontaktplan-Logik im browserbasierten Editor
• Ausführung des Programms im Simulationsmodus
• Überwachung des Druck-Tags, Mittelwerts, Sigmas und der Alarm-Bits im Variablen-Panel
• Einspeisung analoger Störungen in das Drucksignal
• Beobachtung des simulierten Pumpenzustands und der Fehlerreaktion

Nützliche Störungsmuster zur Einspeisung

Für Pumpen-Anomalietests sind die informativsten Fälle:

• analoge Drift, um allmähliche Verschlechterung zu simulieren
• Rechteck-Störung, um instabiles Prozessverhalten zu simulieren
• Erhöhung der Rauschamplitude, um Kavitationsbeginn oder Druckflattern zu simulieren
• Stufenänderung plus Oszillation, um Erholungslogik und Persistenz-Timing zu testen

Es geht nicht darum, theatralische Fehler zu erzeugen. Es geht darum, wiederholbare, begrenzte Fehlersignaturen zu erstellen und zu verifizieren, dass die Logik wie geplant reagiert.

Was digitale Zwillingsvalidierung hier bedeutet

„Digitale Zwillingsvalidierung“ sollte vorsichtig verwendet werden. In diesem Kontext bedeutet es, Steuerungslogik gegen ein realistisches simuliertes Gerätemodell und beobachtbares Prozessverhalten vor der Bereitstellung zu validieren. Es bedeutet nicht, dass die Simulation ein zertifizierter Ersatz für die Standortabnahmeprüfung (SAT), SIL-Verifizierung oder Anlageninbetriebnahme ist.

Diese Grenze ist wichtig. Ein Simulator kann Logikfehler, Sequenzierungsfehler und schlechte Fehlerbehandlung frühzeitig aufdecken. Er kann nicht die Feldverkabelung, die Qualität der Instrumenteninstallation, die hydraulische Realität oder die Reaktion des Bedieners unter tatsächlichen Anlagenbedingungen zertifizieren. Jeder, der diese Kategorien verwischt, verkauft Komfort statt technischer Beweise.

Ein glaubwürdiger Projektdatensatz ist ein kompakter Körper technischer Beweise, keine Screenshot-Galerie. Wenn Sie möchten, dass die Arbeit von einem leitenden Ingenieur, Ausbilder oder Personalverantwortlichen überprüft werden kann, dokumentieren Sie die Logik so, wie es ein Steuerungssystem verdient, dokumentiert zu werden.

Verwenden Sie diese Struktur:

Geben Sie an, was als erfolgreiches Verhalten zählt. Beispiel: „Die SPS muss innerhalb von 1,0 Sekunden nach anhaltender Druckinstabilität einen statistischen Anomaliealarm ausgeben und die Pumpe abschalten, wenn die Anomalie für 2,0 Sekunden im Auto- und Laufzustand anhält.“

Spezifizieren Sie die angewendete Störung: Drift, Oszillation, Amplitudenerhöhung, Ausfall oder gemischter Fehler.

Dokumentieren Sie, was sich nach dem Test geändert hat: Fenstergröße, Persistenz-Timer, Startmaske, Vergleichsschwellenwert oder Modus-Freigabe.

1. Systembeschreibung Definieren Sie das Pumpensystem, den überwachten analogen Tag, die Betriebsmodi und die beabsichtigte Schutzmaßnahme.
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Gerätezustand Zeichnen Sie die relevanten Sprossen, die Tag-Liste, das Abtastintervall, die Array-Länge und den simulierten Pumpenbetriebszustand während des Tests auf.
4. Der eingespeiste Fehlerfall
5. Die vorgenommene Revision
6. Gelernte Lektionen Geben Sie an, was der Test aufgedeckt hat. Gute Beispiele sind Fehlalarme während des Starts, übermäßige Scan-Kosten oder schlechtes Verhalten bei teilweiser Pufferfüllung.

Dies ist die Art von Beweis, die eine technische Überprüfung unterstützt. Sie zeigt Ursache, Wirkung, Revision und Urteilsvermögen. Ein Screenshot allein zeigt meist nur, dass jemand einen Bildschirm aufgenommen hat.

Statistische Anomalielogik sollte als diagnostische oder schützende Erweiterung behandelt werden, sofern sie nicht formell anders konstruiert wurde. Sie ist nicht automatisch eine Sicherheitsfunktion, nur weil sie Geräte abschaltet.

Drei Grenzen sind es wert, klar benannt zu werden:

Wenn die Funktion Teil eines sicherheitsgerichteten Systems ist, muss sie gemäß den relevanten Anforderungen des Sicherheitslebenszyklus entworfen, validiert und gewartet werden. Statistische Neuheit befreit niemanden von der Disziplin nach IEC 61508 oder IEC 61511 (IEC, 2010; IEC, 2016).

• Ein Varianzalarm ist kein SIL-Anspruch.

Simulation kann das Logikverhalten validieren und Fehler frühzeitig aufdecken, ersetzt aber nicht FAT, SAT, Schleifenprüfungen oder die Inbetriebnahme am tatsächlichen Prozess.

• Simulation ist kein Feldbeweis.

Ein Anlauftransient, ein Ventilhub oder eine Betriebsübertragung können wie ein Fehler aussehen, wenn die Logik nicht durch den Prozesszustand gesteuert wird.

• Anomalieerkennung erfordert Modus-Kontext.

Für eine breitere Zuverlässigkeitspraxis betont die Literatur zur Zustandsüberwachung konsequent, dass die Qualität der Fehlererkennung von der Signalqualität, dem Betriebskontext und der Validierung gegen bekannte Fehlersignaturen abhängt, nicht vom bloßen Vorhandensein eines Algorithmus (Jardine et al., 2006; Lei et al., 2020). Mit anderen Worten: Eine Formel ist noch keine Methode.

- IEC 61131-3: Programmierbare Steuerungen — Teil 3 - IEC 61508 Familie der funktionalen Sicherheitsnormen - exida Ressourcen für funktionale Sicherheit und Validierung - NAMUR NE 107 Empfehlung zur Statussignalisierung - Digitaler Zwilling in der Industrie: Stand der Technik (DOI)