Programmierung von Latch- und First-Out-Alarmen bei intermittierendem Signalverlust

Zur Diagnose von intermittierendem Signalverlust in SPS-Systemen benötigen Ingenieure in der Regel zwei Dinge: einen Latch-Mechanismus, der einen transienten Fehler erfasst, und eine First-Out-Alarmlogik, die bei einer Fehlerkaskade die auslösende Ursache bewahrt. In OLLA Lab kann ein Rechtecksignal-Test verwendet werden, um dieses Verhalten vor der Live-Inbetriebnahme sicher zu validieren.

Intermittierende Fehler sind oft keine „mysteriösen Ausfälle“, sondern schnelle Schaltvorgänge. Eine lockere Sensorleitung, Kontaktverschleiß oder prellende Kontakte können den Zustand so schnell ändern, dass die SPS reagiert und den Prozess abschaltet, während das HMI keinen stabilen aktiven Alarm anzeigt.

Während interner Stresstests in OLLA Lab führte die Anwendung einer 10-Hz-Rechtecksignal-Störung auf eine nicht verriegelte Motorfreigabe zu 600 Zustandsänderungen pro Minute. [Methodik: 1 digitaler Eingangstest / Basislinie für nicht verriegelte Freigabe / einzelner 60-Sekunden-Durchlauf] Dies stützt eine wichtige Erkenntnis: Transiente Fehler können weitaus schneller takten, als Bediener auf einem Bildschirm zuverlässig beobachten können. Dies beweist keine Feldausfallraten oder anlagenweite Alarmleistung.

Ein „Simulation-Ready“-Ingenieur ist nicht nur jemand, der Kontaktplan-Syntax zeichnen kann. Es ist jemand, der Logik vor Erreichen eines Live-Prozesses beweisen, beobachten, diagnostizieren und gegen realistisches, abnormales Verhalten absichern kann. Dieser Unterschied ist entscheidend. Syntax ist billig; Fehler bei der Inbetriebnahme sind es nicht.

Der „Vibrationsfehler“ ist meist eine intermittierende elektrische Unterbrechung, kein Software-Geist. Häufige Ursachen sind Kontaktverschleiß (Fretting), lockere Anschlüsse, degradierte Kabel, Steckverbinderverschleiß und mechanisches Kontaktprellen unter Stoß- oder Vibrationsbelastung.

Die steuerungstechnische Konsequenz ist eindeutig. Ein digitaler Eingang, der stabil bleiben sollte, beginnt zwischen `True` und `False` zu flattern. Wenn dieser Eingang Teil einer Freigabe-, Störungs-, Prüf- oder Rückmeldekette ist, kann die SPS innerhalb ihres Zyklus reagieren, selbst wenn die Störung zu kurz für eine HMI-Aktualisierung oder ein Beobachtungsfenster des Bedieners ist.

Diese zeitliche Diskrepanz ist das eigentliche Problem. SPS-Zykluszeiten liegen üblicherweise im Millisekundenbereich, während das HMI-Update-Verhalten langsamer ist und oft durch Kommunikation, Abfrageintervalle und Anzeigelogik gefiltert wird. Die Maschine stoppt. Der Alarm verschwindet. Das Betriebspersonal nennt es zufällig. Meistens ist es das nicht.

Häufige Quellen für intermittierenden Signalverlust

• Reibkorrosion an Klemmenblöcken oder Relaiskontakten
• Lockere Feldverdrahtung an Rangierverteilern oder Geräteanschlüssen
• Degradierte M12- oder ähnliche Steckverbinder an vibrierenden Anlagen
• Prellen von Endschaltern bei Stößen oder schlechter mechanischer Ausrichtung
• Kabelermüdung in der Nähe von beweglichen Anlagenteilen, Scharnieren oder Energieführungsketten
• Unterbrechungen der Sensorstromversorgung durch grenzwertige Versorgung oder Erdungsfehler

Eine nützliche Korrektur an dieser Stelle: Nicht jeder flackernde Eingang benötigt sofort eine Entprellung. Wenn das Signal einen tatsächlichen Verlust einer Freigabe oder Prüfung darstellt, kann eine zu frühe Maskierung den auslösenden Fehler verbergen. Rauschfilterung und Fehlererfassung sind verwandte, aber nicht identische Probleme.

Ein Rechtecksignal ist das korrekte Testmuster für die Injektion diskreter intermittierender Fehler, da es ein deterministisches boolesches Umschalten erzwingt. Praktisch verhält es sich wie ein Draht oder Kontakt, der wiederholt die Verbindung herstellt und unterbricht.

In OLLA Lab kann das Rechtecksignal an einen digitalen Eingang gebunden werden, um den Logikpfad zu belasten, der von diesem Eingang abhängt. Hier wird die Plattform operativ nützlich: Sie fragen nicht mehr, ob der Zweig vernünftig aussieht, sondern ob die Steuerungssequenz tatsächlich einen transienten Fehler einfängt, die auslösende Ursache bewahrt und den Prozess in einen sicheren Zustand überführt.

Wellenformanwendung bei Fehlertests

| Wellenform | Beste Verwendung | Ingenieurtechnischer Zweck | |---|---|---| | Sinuswelle | Analoge Drift oder zyklische Prozessvariationen | Beobachtung schleichender Wertänderungen und Schwellwertverhalten | | Sägezahn | Befehlsrampen oder Nachlaufverhalten | Test von analogem Nachlauf und Rücksetzmustern | | Rechteckwelle | Diskretes boolesches Umschalten | Simulation von Wackelkontakten, prellenden Kontakten oder intermittierenden Prüfsignalen |

Es geht nicht um die Vielfalt der Wellenformen an sich. Es geht darum, das Fehlermodell an den Ausfallmodus anzupassen. Ein Wackelkontakt ist keine Sinuswelle.

Eine Latch-Schaltung (Selbsthaltung) wird verwendet, um den Nachweis eines Fehlers zu bewahren, nachdem die auslösende Bedingung verschwunden ist. Ohne diese Speicherung löst die SPS möglicherweise korrekt aus, hinterlässt aber keinen dauerhaften Hinweis auf das Geschehene.

Es gibt zwei gängige Ansätze im Kontaktplan: ein Selbsthaltemuster und explizite Latch/Unlatch-Befehle. Beide können gültig sein, sind aber nicht austauschbar.

Selbsthaltung vs. OTL/OTU

Verwendet einen eigenen Kontakt des Ausgangs in einem parallelen Zweig, um den Zustand nach dem Eintreten der Bedingung zu halten.

• Standard-Selbsthaltung
• Oft geeignet für nicht-retentives Steuerungsverhalten
• Fällt bei Stromausfall typischerweise ab
• Üblich in der Motorsteuerung und bei einfachen Alarm-Haltekreisen

Verwendet explizites retentives Speicherverhalten.

• Latch/Unlatch (OTL/OTU oder äquivalente retentive Befehle)
• Bit bleibt `True`, bis ein gezieltes Rücksetzen erfolgt
• Überdauert Logikübergänge expliziter als ein einfacher Selbsthaltezweig
• Erfordert ein diszipliniertes Rücksetzdesign und eine Quittierungslogik für den Bediener

Die ingenieurtechnische Wahl hängt davon ab, was gespeichert werden muss, wie lange und über welche Systemzustandsänderungen hinweg. Retention ist nützlich; versehentliche Retention ist ein Ärgernis mit bürokratischem Aufwand.

### Beispiel: Einfache Latch-Fehlererfassung

Ziel: Erfassung eines kurzen Verlusts von `Motor_Run_Proof`, damit der Alarm nach Signalwiederkehr sichtbar bleibt.

| Motor_Commanded_On | /Motor_Run_Proof |--------------------(OTL Fault_Motor_Run_Proof_Latched) |

| Reset_Faults_PB |-----------------------------------------(OTU Fault_Motor_Run_Proof_Latched) |

Operative Bedeutung:

• Wenn der Motor eingeschaltet ist und die Laufprüfung verloren geht, wird das Fehlerbit verriegelt.
• Der Fehler bleibt aktiv, auch wenn die Laufprüfung zurückkehrt.
• Nach der Diagnose ist ein gezieltes Rücksetzen erforderlich.

Das ist die Mindeststruktur, um einen transienten Fehler zu erfassen. Es ist noch keine First-Out-Logik.

Die First-Out-Alarmlogik bewahrt den auslösenden Alarm, wenn ein Fehler eine Kaskade von Sekundäralarmen auslöst. In der Praxis beantwortet sie die einzige Frage, die Bediener und Techniker zuerst stellen müssen: Was ist zuerst passiert?

ISA-18.2 ist ein Standard für das Alarmmanagement in der Prozessindustrie. Während die Implementierungen je nach System und Philosophie variieren, unterstützen die Prinzipien der Alarmrationalisierung des Standards nachdrücklich Alarmdesigns, die Alarmfluten verhindern und eine sinnvolle Reaktion des Bedieners bewahren. First-Out-Logik ist eine gängige und vertretbare Methode, um genau dies bei Kaskadenausfällen zu erreichen.

Hier ist das Ausfallmuster: Ein vibrationsbedingter intermittierender Ausfall stoppt den Hauptmotor. Sobald der Motor stoppt:

• kann der Durchfluss abfallen,
• kann der Druck zusammenbrechen,
• kann die Temperaturregelung driften,
• können nachgeschaltete Freigaben abfallen.

Wenn jede resultierende Bedingung gleichermaßen alarmiert, wird die auslösende Ursache unter den Konsequenzen begraben. Das ist keine bessere Sichtbarkeit. Es ist nur lautere Verwirrung.

Warum First-Out bei Kaskadenausfällen wichtig ist

• Es bewahrt das auslösende Ereignis für die Diagnose
• Es unterdrückt irreführende Alarmfluten
• Es verbessert die Qualität der Bedienerreaktion
• Es unterstützt die Fehlerbehebung nach dem Ereignis und die Alarmüberprüfung
• Es entspricht rationalen Alarmdesignprinzipien gemäß ISA-18.2-Governance

Standard-First-Out-Konzept

Ein gängiges Muster ist das Setzen eines globalen `First_Out_Active`-Bits, wenn der erste qualifizierende Alarm auftritt, und das anschließende Blockieren nachfolgender Kandidaten.

// Kandidat 1: Vibrations- / intermittierender Prüffehler | /First_Out_Active | Fault_Vibration_Latched |---------(OTL FirstOut_Vibration) | | /First_Out_Active | Fault_Vibration_Latched |---------(OTL First_Out_Active) |

// Kandidat 2: Folgefehler niedriger Durchfluss | /First_Out_Active | Alarm_Low_Flow |-----------------(OTL FirstOut_Low_Flow) | | /First_Out_Active | Alarm_Low_Flow |-----------------(OTL First_Out_Active) |

// Kandidat 3: Folgefehler niedriger Druck | /First_Out_Active | Alarm_Low_Pressure |-------------(OTL FirstOut_Low_Pressure) | | /First_Out_Active | Alarm_Low_Pressure |-------------(OTL First_Out_Active) |

// Reset | Reset_First_Out_PB |----------------------------------(OTU First_Out_Active) | | Reset_First_Out_PB |----------------------------------(OTU FirstOut_Vibration) | | Reset_First_Out_PB |----------------------------------(OTU FirstOut_Low_Flow) | | Reset_First_Out_PB |----------------------------------(OTU FirstOut_Low_Pressure) |

Ingenieurtechnische Absicht:

Bild-Alternativtext: Screenshot des OLLA Lab Variablen-Panels, das eine First-Out-Alarmsequenz zeigt. Das Vibrationssensor-Bit ist als „True“ verriegelt, während nachfolgende Alarme für niedrigen Durchfluss und Druck daran gehindert werden, den primären HMI-Alarm zu aktivieren.

Ein praktischer Hinweis: First-Out-Logik sollte mit klaren Qualifizierungsregeln entworfen werden. Wenn Sie Störalarme, veraltete Bits oder schlecht zurückgesetzte Zustände in den Kandidatenpool lassen, wird die Sequenz treu die falsche Antwort bewahren.

1. Der erste gültige Alarm setzt sein eigenes First-Out-Bit.
2. Dasselbe Ereignis setzt `First_Out_Active`.
3. Sobald `First_Out_Active` gesetzt ist, können spätere Alarme die auslösende Ursache nicht überschreiben.
4. Das Rücksetzen erfolgt nur durch einen gezielten Diagnose-Workflow.

Ampergon Vallis validiert First-Out-Verhalten, indem ein kontrollierter intermittierender Fehler in einen simulierten Eingangspfad injiziert wird und beobachtet wird, ob die Logik das auslösende Ereignis erfasst, nachgeschaltetes Alarmchaos unterdrückt und den Prozess in einen sicheren Zustand versetzt. Das ist der begrenzte Anspruch.

In OLLA Lab sollte „Digital Twin Validation“ operativ verstanden werden, nicht romantisch. Es bedeutet, Kontaktplan-Zustand, E/A-Zustand und simuliertes Anlagenverhalten unter einem definierten Fehlerfall zu vergleichen, um zu verifizieren, dass die Steuerungsphilosophie vor der Live-Bereitstellung wie beabsichtigt funktioniert.

Typischer OLLA Lab Workflow für die Validierung intermittierender Fehler

1. Signalquelle binden Weisen Sie den OLLA Lab Rechtecksignalgenerator einem digitalen Eingang wie `DI_03_Vibration_Sw` oder `Motor_Run_Proof` zu.
2. Simulierten Prozess ausführen Starten Sie das relevante 3D- oder webbasierte Anlagenszenario und stellen Sie den normalen Betriebszustand her.
3. Intermittierenden Fehler injizieren Lösen Sie die Rechteckwelle mit der gewählten Frequenz aus, um ein wiederholbares `True/False`-Toggeln zu erzeugen.
4. Variablen-Panel beobachten Bestätigen Sie, dass das auslösende Fehlerbit verriegelt wird, das First-Out-Bit korrekt beansprucht wird und Sekundäralarme daran gehindert werden, die erste Position einzunehmen.
5. Sicherheitszustand verifizieren Prüfen Sie, ob Ausgänge, Freigaben und Sequenzzustand in den beabsichtigten sicheren Zustand übergehen.
6. Zurücksetzen und erneut testen Setzen Sie die Sequenz gezielt zurück und führen Sie die Störung erneut aus, um die Wiederholbarkeit zu bestätigen.

Dieser Workflow ist nützlich, da er eine Klasse von Inbetriebnahmetätigkeiten probt, die an realen Anlagen umständlich, riskant oder physisch belastend sind. Das absichtliche Schütteln eines Live-Feldgeräts ist ein schlechter Weg, um sich bei der Instandhaltung beliebt zu machen.

Korrektes Verhalten muss definiert werden, bevor der Test beginnt. Andernfalls bewundern Ingenieure Animationen, lernen aber sehr wenig.

Für ein verriegeltes First-Out-Design bedeutet „korrekt“ normalerweise:

• der auslösende Fehler wird erfasst, auch wenn sich das Signal erholt,
• der Prozess geht in einen definierten sicheren Zustand über,
• Sekundäralarme können intern noch existieren, überschreiben aber nicht die First-Out-Anzeige,
• das Rücksetzen ist gezielt und kontrolliert,
• die Sequenz ist über mehrere Testläufe hinweg wiederholbar.

Das ist die praktische Bedeutung von „Simulation-Ready“ im Steuerungskontext: Der Ingenieur kann das erwartete Verhalten angeben, den Fehler injizieren, das Ergebnis beobachten und die Logik überarbeiten, falls das Verhalten nicht der Steuerungsphilosophie entspricht.

Ein kompaktes Paket für den technischen Nachweis

Erstellen Sie bei der Dokumentation dieser Arbeit Nachweise statt einer Screenshot-Galerie. Verwenden Sie diese Struktur:

Dokumentieren Sie, was sich nach dem Test geändert hat: Latch-Platzierung, Rücksetzbedingungen, Alarmqualifizierung oder First-Out-Blockierlogik.

1. Systembeschreibung Definieren Sie die Maschine oder den Prozessabschnitt, die relevanten E/A und das Steuerungsziel.
2. Operative Definition von „korrekt“ Geben Sie genau an, was die Logik bei Fehler, Alarm, Übergang in den sicheren Zustand und Rücksetzen tun sollte.
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die Logik zusammen mit dem Anlagenzustand oder Sequenzzustand, den sie steuert.
4. Der injizierte Fehlerfall Protokollieren Sie den gestörten Eingang, die verwendete Wellenform, Frequenz, Dauer und die erwartete Konsequenzkette.
5. Die vorgenommene Überarbeitung
6. Erkenntnisse Halten Sie die ingenieurtechnische Schlussfolgerung fest, insbesondere dort, wo die ursprüngliche Logik versagte oder mehrdeutige Informationen für den Bediener lieferte.

Dieses Format ist überzeugender als ein poliertes Dashboard-Bild, da es Urteilsvermögen, Fehlerbehandlung und Revisionsdisziplin zeigt. Arbeitgeber und Prüfer bevorzugen im Allgemeinen den Nachweis von Urteilsvermögen gegenüber dem Nachweis von Mausklicks.

Entprell-Logik ist angemessen, wenn das Signal verrauscht ist, aber keine bedeutsame abnormale Bedingung darstellt, die sofort erfasst werden muss. Latch-plus-First-Out-Logik ist angemessen, wenn ein transienter Fehler einen echten Defekt, Ausfall oder Verlust einer Prüfung anzeigt, der für die Diagnose bewahrt werden muss.

Der Unterschied ist einfach: - Entprellung fragt: „Sollte ich diese kurze Instabilität ignorieren?“ - Latch + First-Out fragt: „Wenn diese Instabilität real ist, wie bewahre ich die auslösende Ursache?“

Viele Systeme benötigen beides, aber in der richtigen Reihenfolge und mit der richtigen Absicht. Das Filtern eines Störsignals kann die Robustheit verbessern. Das Wegfiltern des einzigen Beweises für ein gefährliches oder produktionskritisches Ereignis ist eine andere Leistung.

Der Ansatz wird durch etablierte Literatur zu Alarmmanagement, funktionaler Sicherheit und Simulation gestützt, wobei jede Quelle einen anderen Teil des Problems regelt.

Relevante Standards und Literatur

• ISA-18.2 unterstützt eine disziplinierte Alarmphilosophie, Rationalisierung, Priorisierung und das Management von Alarmfluten in Prozessumgebungen.
• IEC 61508 bietet den breiteren Rahmen für funktionale Sicherheit für sicherheitsbezogene elektrische, elektronische und programmierbare Systeme. Sie schreibt nicht Ihren exakten First-Out-Zweig vor, unterstreicht aber die Notwendigkeit für deterministisches Verhalten, Validierung und Lebenszyklusdisziplin.
• exida-Leitlinien und Industriepraxis betonen konsequent den Nachweis von Verhalten, den Umgang mit abnormalen Bedingungen und die Validierung vor der Bereitstellung in sicherheitsrelevanten Kontexten.
• Digital-Twin- und Simulationsliteratur in den Ingenieurwissenschaften unterstützt Simulation als valide Umgebung zum Testen von Steuerungsreaktionen, Bedienerinteraktion und Fehlerszenarien vor dem Live-Betrieb.

Der enge Anspruch hier ist vertretbar: Simulation ist ein glaubwürdiger Ort, um Alarm- und Fehlerbehandlungslogik vor der Inbetriebnahme zu validieren. Der breitere Anspruch, dass Simulation allein Standortkompetenz verleiht, wäre unseriös.

Intermittierender Signalverlust ist schwer zu diagnostizieren, da der Fehler verschwinden kann, bevor der Bediener ihn jemals sieht. Die ingenieurtechnische Antwort ist kein Raten. Es geht darum, den transienten Fehler mit einem Latch einzufangen, die auslösende Ursache mit First-Out-Logik zu bewahren und die Sequenz gegen eine realistische Fehlerinjektion zu validieren, bevor der Code die Live-Anlage erreicht.

Hier passt OLLA Lab glaubwürdig hinein. Es ist ein webbasierter Kontaktplan- und Digital-Twin-Simulator, der es Ingenieuren ermöglicht, Logik zu erstellen, Simulationen auszuführen, E/A und Variablen zu überwachen und wiederholbare Fehler wie Rechteck-Toggeln zu injizieren, um zu testen, ob die Sequenz tatsächlich standhält. Richtig eingesetzt, ist es eine Probenumgebung für das Urteilsvermögen bei der Inbetriebnahme, kein Ersatz dafür.

- IEC 61508 Functional Safety overview - exida Functional Safety and Automation resources - Åström & Hägglund, *Advanced PID Control* (ISA) - Skogestad (2003), PID tuning rules00062-8) - Tao et al. (2019), Digital Twin in Industry