Programmierung von Sicherheitsverriegelungen und Not-Halt-Ketten: Ein Leitfaden für defensive SPS-Programmierung

Defensive SPS-Programmierung bedeutet den Nachweis, dass Freigabebedingungen, Verriegelungen, Not-Halt-Rücksetzlogik und PID-Ausgangsbegrenzungen die Anlage unter Fehlerbedingungen in einen sicheren Zustand überführen. Die ingenieurtechnische Aufgabe besteht nicht nur darin, eine gültige Kontaktplan-Syntax zu schreiben, sondern das fehlerbewusste Verhalten vor der Inbetriebnahme anhand einer realistischen Prozessreaktion zu validieren.

Ein häufiges Missverständnis ist, dass ein Kontaktplan-Programm „sicher“ ist, sobald die Sequenz im Normalbetrieb funktioniert. Das ist nicht der Fall. Sicherheitsrelevantes Steuerungsverhalten definiert sich darüber, was die Logik tut, wenn ein Eingangssignal ausfällt, eine Abschaltung mitten in der Sequenz erfolgt oder ein Analogwert fehlerhaft ist.

Ein aktueller interner Benchmark von Ampergon Vallis stützt diese Unterscheidung: Bei einer Analyse von 2.500 simulierten Pumpenstart-Sequenzen, die in OLLA Lab-Inbetriebnahmeszenarien erstellt wurden, fehlte bei 68 % der ersten Kontaktplan-Entwürfe eine manuelle Rücksetzverriegelung nach einer Not-Halt-Bedingung [Methodik: 2.500 Simulationsläufe von Lernenden und Anwendern; Aufgabe definiert als Implementierung einer Pumpenstart-Sequenz mit Not-Halt-Wiederanlauflogik; Vergleichsbasis war ein normgerechtes Wiederanlaufverhalten, das ein bewusstes manuelles Rücksetzen erfordert; Zeitfenster Januar–März 2026]. Diese Kennzahl stützt einen engen Punkt: Wiederanlauflogik wird in der Simulation häufig falsch implementiert. Sie misst weder Feldvorfallraten noch die Normenkonformität in der Industrie oder die Kompetenz des Bedienpersonals.

In diesem Artikel bedeutet „Simulation-Ready“ etwas Operatives: Ein Ingenieur kann die Steuerungslogik vor Erreichen eines realen Prozesses beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten absichern. Die Syntax ist nur die Aufnahmeprüfung. Die Beurteilung der Inbetriebnahme ist die eigentliche Arbeit.

Eine Freigabebedingung (Permissive) ist eine Vorbedingung, die erfüllt sein muss, bevor eine Sequenz gestartet werden darf. Eine Verriegelung (Interlock) ist eine kontinuierlich ausgewertete Bedingung, die erforderlich ist, damit die Sequenz weiterläuft; wird sie verletzt, muss das System in einen definierten sicheren Zustand überführt werden.

Diese Unterscheidung ist in der Formulierung grundlegend und wird in der Implementierung routinemäßig falsch gehandhabt. Der Kontaktplan sieht oft sauber aus. Die Maschine bleibt jedoch unüberzeugt.

Freigabebedingungen sind Startbedingungen

Freigabebedingungen werden vor der Einleitung einer Aktion, eines Modus oder eines Sequenzschritts geprüft.

- Zweck: Verhindern des Starts, wenn erforderliche Bedingungen nicht erfüllt sind - Auswertungszeitpunkt: Typischerweise bei Startanforderung, Schrittübergang oder Moduswechsel - Typische Beispiele:

• Tankfüllstand über Minimum vor Pumpenstart
• Luftdruck in Ordnung vor Zylinderbewegung
• Antrieb bereit vor Förderbandfreigabe
• Rezept geladen vor Chargenstart

In der Sprache der Prozesssicherheit sind Freigabebedingungen nicht dasselbe wie Schutzabschaltungen. Nach dem Denken gemäß IEC 61511 sind sie aktivierende Bedingungen, nicht die letzte Verteidigungslinie.

Verriegelungen sind kontinuierliche Laufbedingungen

Verriegelungen werden während des Betriebs kontinuierlich ausgewertet und müssen bei Verletzung eine sichere Reaktion erzwingen.

- Zweck: Stoppen, Sperren oder Abschalten der Energieversorgung von Anlagen, wenn ein unsicherer oder ungültiger Zustand auftritt - Auswertungszeitpunkt: Kontinuierlich während des aktiven Zustands - Typische Beispiele:

• Hoch-Hoch-Druckabschaltung schließt Zulaufventil
• Motorüberlastfehler unterbricht Laufbefehl
• Schutztür offen entfernt Bewegungsfreigabe
• Durchfluss-Verriegelung deaktiviert Heizung

Eine Freigabebedingung sagt: „Du darfst starten.“ Eine Verriegelung sagt: „Du darfst nur so lange weitermachen, wie dies wahr bleibt.“ Das ist keine Semantik. Es ist der Unterschied zwischen geordneter Startlogik und tatsächlicher Fehlerbeherrschung.

Wie sich dies im Kontaktplan darstellt

Die Unterscheidung wird deutlicher, wenn sie auf das Verhalten im Kontaktplan abgebildet wird:

- Start-Taster: `XIC` - Automatikmodus gewählt: `XIC` - Mindestfüllstand in Ordnung: `XIC` - Keine aktive Störung: `XIO` auf Störungsbit, falls Störungsbit bei Fehler wahr ist

• Muster Freigabebedingung
• Ausgangsspule oder Lauf-Selbsthaltung zieht nur an, wenn alle Startbedingungen wahr sind

- Bestehende Lauf-Selbsthaltung oder Sequenz-Aktiv-Bit bleibt nur erregt, solange: - Druck in Ordnung: `XIC` - Überlast gelöscht: `XIC` - Not-Halt in Ordnung: `XIC` - Schutzgitter geschlossen: `XIC`

• Muster Verriegelung
• Jede verletzte Bedingung unterbricht den Strompfad und erzwingt einen sicheren Zustand

In der Szenariodokumentation von OLLA Lab können Inbetriebnahmeanmerkungen verwendet werden, um diese Kategorien explizit zu trennen: Was muss zum Starten wahr sein, was muss zum Laufen wahr bleiben und in welchen Zustand soll der digitale Zwilling bei einer Verletzung übergehen? Hier wird OLLA Lab operativ nützlich.

Eine normgerechte Not-Halt-Implementierung muss einen automatischen Wiederanlauf nach dem Rücksetzen des Stopp-Geräts verhindern; der Wiederanlauf erfordert eine bewusste manuelle Handlung. Dieses Prinzip spiegelt sich in der Maschinensicherheitspraxis gemäß Normen wie IEC 60204-1 und NFPA 79 wider.

Die erste Korrektur ist wichtig: Eine Not-Halt-Funktion ist nicht nur „ein Stopp-Taster im Kontaktplan“. Die Sicherheitsfunktion wird primär durch eine korrekt ausgelegte Hardware-Architektur und sicherheitsgerichtete Komponenten erreicht, wo dies erforderlich ist. Standard-SPS-Logik kann den Status überwachen, das Wiederanlaufverhalten verwalten und nicht-sicherheitsgerichtete Steuerungsaktionen koordinieren, aber sie ist kein Ersatz für eine sicherheitsgerichtete Funktion. Diese Ebenen zu verwechseln ist der Weg, wie teure Fehler zu lehrreichen Erfahrungen werden.

Der Feldzustand und der Logikzustand sind nicht zufällig Gegensätze

Die fehlersichere Feldverdrahtung verwendet üblicherweise einen Öffner-Kontakt (NC) für den Not-Halt, sodass der sichere Zustand Durchgang signalisiert.

- Feldgerätezustand: NC-Kontakt geschlossen, wenn sicher - SPS-Eingangszustand: Eingang liest `1`, wenn der Stromkreis in Ordnung ist - Fehlerverhalten: Betätigen des Not-Halts, Spannungsverlust oder Leitungsbruch steuert den Eingang auf `0`

Deshalb verwendet die Logik oft einen `XIC`-Befehl auf den Not-Halt-Eingang. Der Befehl spiegelt nicht das Symbol des physischen Kontakts wider. Er verifiziert, dass die SPS eine gesunde `1` sieht.

Das erforderliche Wiederanlaufverhalten

Ein korrektes Wiederanlaufmuster muss drei Dinge tun:

• Den Laufbefehl sofort unterbrechen, wenn das Not-Halt-Signal „in Ordnung“ auf falsch geht
• Den Wiederanlauf verriegeln, nachdem der Not-Halt zurückgesetzt wurde
• Ein manuelles Rücksetzen oder einen neuen Startbefehl erfordern, bevor Bewegung oder Prozessaktion fortgesetzt werden

Wenn die Maschine automatisch wieder anläuft, wenn der Pilztaster herausgezogen wird, hat die Logik den grundlegenden Wiederanlauftest nicht bestanden. Der Kontaktplan mag syntaktisch gültig sein. Das Verhalten ist dennoch falsch.

Eine typische Kontaktplan-Struktur

Ein normgerechtes Steuerungsmuster enthält oft:

- Strompfad 1: Not-Halt-Status „in Ordnung“

• `XIC ESTOP_OK` steuert bei Bedarf ein internes Bit „in Ordnung“ an

- Strompfad 2: Störungs- oder Rücksetz-erforderlich-Verriegelung

• Verlust von `ESTOP_OK` setzt ein `RESET_REQUIRED`-Bit
• `RESET_REQUIRED` bleibt verriegelt, bis der Bediener `RESET_PB` drückt

- Strompfad 3: Laufbefehl-Selbsthaltung - Ausgang: `RUN_CMD`

• `XIC START_PB`
• `XIC ESTOP_OK`
• `XIO RESET_REQUIRED`
• `XIO TRIP_ACTIVE`
• Selbsthaltungszweig um den Start mittels Laufbefehl-Bit

- Strompfad 4: Manuelles Rücksetzen

• `XIC RESET_PB`
• `XIC ESTOP_OK`
• Rücksetzen (OTU) `RESET_REQUIRED`

Dies ist ein Implementierungsmuster, keine universelle Vorlage. Das erforderliche Verhalten ist der eigentliche Test: Der Verlust der Not-Halt-Integrität muss zum Abschalten führen, und die Wiederherstellung darf keinen automatischen Wiederanlauf auslösen.

Konzept des Kontaktplans

Sprache: Kontaktplan (Ladder Diagram)

Strompfad 1: Not-Halt-Verlust erkennen und manuelles Rücksetzen anfordern |----[/ESTOP_OK]-------------------------------(OTL RESET_REQUIRED)----|

Strompfad 2: Manuelles Rücksetzen nur erlaubt, wenn Not-Halt-Kreis in Ordnung |----[RESET_PB]----[ESTOP_OK]------------------(OTU RESET_REQUIRED)----|

Strompfad 3: Lauf-Selbsthaltung erfordert Not-Halt in Ordnung und keinen Rücksetz-Zustand |----[START_PB]----[ESTOP_OK]----[/RESET_REQUIRED]----[/TRIP_ACTIVE]----+----(RUN_CMD) | | |----[RUN_CMD]-----------------------------------------------------------+

Strompfad 4: Jeder Verlust der Not-Halt-Integrität unterbricht den Laufbefehl |----[/ESTOP_OK]---------------------------------------------------------(OTU RUN_CMD)----|

Bild-Alternativtext: Screenshot des OLLA Lab Kontaktplan-Editors, der eine normgerechte Not-Halt-Kette zeigt, mit einem XIC-Befehl für den physischen Not-Halt-Eingang und einer manuellen Rücksetzverriegelung, um einen automatischen Motor-Wiederanlauf zu verhindern.

Die PID-Ausgangsbegrenzung (Clamping) ist die harte Begrenzung der Stellgröße, damit der Regler keine Befehle außerhalb definierter Aktor- oder Prozessgrenzen ausgeben kann. Ohne sie kann der Regelkreis physikalisch sinnlose oder mechanisch schädliche Ausgänge anfordern.

Dies ist wichtig, da Analogfehler weniger theatralisch ausfallen als diskrete Abschaltungen. Sie treiben den Prozess einfach länger in die falsche Richtung, was oft schlimmer ist.

Was Begrenzung mathematisch bedeutet

Wenn der unbegrenzte Reglerausgang ist:

MV_raw(t) = Kp e(t) + Ki ∫e(t)dt + Kd de(t)/dt + Bias

dann ist der begrenzte Ausgang:

MV(t) = min(MV_max, max(MV_min, MV_raw(t)))

Wobei:

• `MV_raw` = unbegrenzte Stellgröße
• `MV_min` = untere Ausgangsgrenze
• `MV_max` = obere Ausgangsgrenze

Operativ kann der an das Stellglied gesendete Befehl die definierten Grenzen nicht überschreiten, selbst wenn der Fehlerterm weiter wächst.

Warum unbegrenzter Ausgang gefährlich ist

Unbegrenztes PID-Verhalten verursacht mindestens drei praktische Probleme:

• Aktor-Sättigung
• Ein Ventil-, Frequenzumrichter-, Klappen- oder Heizungsbefehl wird über seinen beabsichtigten Bereich hinaus getrieben
• Selbst wenn die Hardware den Wert zurückskaliert, kann der Regler weiter integrieren, als ob mehr Stellbereich vorhanden wäre

• Prozessschaden
• Eine Heizung kann lange genug auf maximaler Leistung verharren, um das Produkt zu beeinträchtigen
• Ein Zulaufventil kann einen Behälter in Richtung Überlauf oder Drucküberschreitung übersteuern

• Irreführende Diagnose
• Der Regelkreis erscheint „aggressiv“, während das eigentliche Problem darin besteht, dass der Regler einen unmöglichen Ausgang anfordert

Ein 110%-Befehl an ein 100%-Ventil ist keine zusätzliche Regelung. Es ist nur ein Regler, der verkündet, dass er den Bezug zur Realität verloren hat.

Anti-Windup ist die begleitende Regelung

Ausgangsbegrenzung ohne Anti-Windup ist unvollständig. Wenn der Integralanteil weiter akkumuliert, während der Ausgang an einer Grenze feststeckt, speichert der Regler einen Fehler, der später abgebaut werden muss, was oft zu Überschwingen und träger Erholung führt.

Gängige Anti-Windup-Ansätze umfassen:

- Integral-Halten: Integration pausieren, wenn `MV` an einer Grenze liegt und der Fehler ihn weiter in die Sättigung treiben würde - Rückrechnung: Die Differenz zwischen begrenztem und rohem Ausgang zurück in den Integrator führen - Bedingte Integration: Nur integrieren, wenn Stellbereich verfügbar bleibt

Für viele Schulungs- und Inbetriebnahmefälle ist die operative Definition ausreichend: Wenn der Ausgang nach oben begrenzt ist, nicht weiter positiven Fehler integrieren; wenn nach unten begrenzt, nicht weiter negativen Fehler integrieren.

Praktische Beispiele für Begrenzungen

Typische Begrenzungsbereiche hängen vom Prozess und dem Stellglied ab:

- Ventilbefehl: `0 % bis 100 %` - Heizleistung: `0 % bis 80 %`, um Produkt oder Ausrüstung zu schützen - Mindest-Rezirkulationsventil: `20 % bis 100 %`, um den Pumpenschutz-Durchfluss zu erhalten - Lüfterdrehzahl-Sollwert: `30 % bis 95 %`, um Blockieren oder instabilen Betrieb im unteren Bereich zu vermeiden

Dies sind technische Grenzen, keine ästhetischen Vorlieben. Der Prozess erklärt sie meistens, wenn sich jemand die Mühe macht, ihn zu fragen.

Wie man dies in OLLA Lab beobachtet

Das PID-Dashboard und das Variablen-Panel von OLLA Lab können verwendet werden, um Folgendes zu beobachten:

• Abweichung der Prozessvariablen
• Sollwertverfolgung
• Reglerausgang
• Änderungen des analogen Signals
• Ausgangssättigung
• Reaktion vor und nach dem Hinzufügen der Begrenzungslogik

In einer risikobewussten Simulation können Sie einen Messumformer absichtlich auf einen niedrigen Wert ausfallen lassen, beobachten, wie der Regelkreis in Richtung maximaler Anforderung steuert, dann Ausgangsgrenzen hinzufügen und die Reaktion des digitalen Zwillings vergleichen. Das ist eine nützliche Probe der Inbetriebnahmelogik. Es ist kein SIL-Verifizierungs-Workflow und sollte auch nicht als solcher beschrieben werden.

Defensive SPS-Programmierung bedeutet, Logik für die Zustände zu schreiben, die Bediener nicht wollen, die in Anlagen aber letztlich doch auftreten. Eine Sequenz, die nur funktioniert, wenn jeder Sensor sich korrekt verhält, ist keine robuste Steuerungslogik.

Beginnen Sie mit einem definierten sicheren Zustand

Jede Verriegelung sollte auf eine spezifische sichere Reaktion abbilden.

Beispiele:

- Pumpensystem: Pumpe stoppen, Druckventil schließen, Bediener alarmieren - Heizungsanlage: Heizungsfreigabe entfernen, Spülung oder Zirkulation beibehalten, falls erforderlich - Förderband: Bewegungsbefehl entfernen, Störungsleuchte aktiv halten - Tankbefüllung: Zulaufventil schließen, Wiederanlauf bis zur Quittierung sperren

Der sichere Zustand muss pro System definiert werden. „Alles stoppen“ ist nicht immer sicher. Manchmal ist es nur dramatisch.

Bauen Sie Verriegelungen als beobachtbare Logik, nicht als vage Absicht

Ein verteidigbares Verriegelungsdesign enthält üblicherweise:

• die Auslösebedingung
• die erforderliche Aktion
• das Verriegelungsverhalten, falls vorhanden
• die Rücksetzbedingung
• die Bedieneranzeige
• die Verifizierungsmethode in der Simulation oder FAT

Zum Beispiel:

- Auslöser: `PRESSURE_HH = 1` - Aktion: `PUMP_RUN_CMD` entriegeln, `FEED_VALVE_CMD` schließen - Verriegelung: `HH_PRESS_TRIP` setzen - Rücksetzen: Bediener-Rücksetzen nur erlaubt, nachdem der Druck unter den Rücksetzschwellenwert gefallen ist - Anzeige: Alarmbit und HMI-Meldung - Verifizierung: Hoch-Hoch-Druck in der Simulation während des Laufzustands einspeisen und Abschaltpfad bestätigen

Dies ist der Grad an Spezifität, der ein Steuerungsszenario testbar macht.

Verwenden Sie Freigabebedingungen und Verriegelungen zusammen, nicht austauschbar

Eine robuste Sequenz verwendet oft beides:

• Freigabebedingung vor dem Start
• Saugfüllstand ausreichend
• keine aktive Überlast
• nachgeschaltetes Ventil verfügbar

• Verriegelung während des Laufs
• Niedrig-Saug-Abschaltung
• Überlast-Abschaltung
• Hoch-Druck-Abschaltung
• Not-Halt in Ordnung

Wenn ein niedriger Tankfüllstand nur beim Start und nie während des Betriebs geprüft wird, ist die Logik nicht „einfacher“. Sie ist unvollständig.

Eine risikobewusste virtuelle Inbetriebnahmeumgebung ermöglicht es Ingenieuren, Fehler einzuspeisen, die Reaktion der Ausrüstung zu beobachten, die Logik zu überarbeiten und das exakte Szenario erneut auszuführen, ohne Menschen oder Hardware unnötigen Risiken auszusetzen. Das ist das begrenzte Wertversprechen.

Man lehrt Fehlerbehandlung nicht durch Improvisation an einer laufenden Anlage. Anlagen sind im Allgemeinen wenig begeistert davon, als Lehrmittel verwendet zu werden.

Sichere Fehlereinspeisung

Im Simulationsmodus von OLLA Lab können Benutzer Logik ausführen, Eingänge umschalten und Variablenzustände ohne physische Hardware inspizieren. Das unterstützt das bewusste Testen abnormaler Bedingungen wie:

• Äquivalente zu Leitungsbrüchen
• Sensorausfall
• Not-Halt-Betätigung während einer aktiven Sequenz
• Ausfall der Rückmeldung
• Analoge Ausschläge außerhalb des normalen Betriebsbereichs
• Alarm- und Abschalt-Schwellenwerte

Der ingenieurtechnische Wert ist die Wiederholbarkeit. Derselbe Fehler kann nach jeder Logiküberarbeitung erneut eingeführt werden, bis die Reaktion korrekt ist.

Validierung des digitalen Zwillings

Validierung des digitalen Zwillings bedeutet in diesem Artikel, das Verhalten des Kontaktplan-Zustands mit einem realistischen virtuellen Ausrüstungsmodell zu vergleichen, um zu verifizieren, dass die Steuerungslogik das beabsichtigte physische Ergebnis liefert.

Diese Definition ist absichtlich eng gefasst. Sie bedeutet nicht, dass das Modell eine physikalisch perfekte Kopie ist, und impliziert keine formale Konformität durch Assoziation.

In OLLA Lab kann dies beinhalten, zu beobachten, ob:

• eine Pumpe nur startet, wenn Freigabebedingungen erfüllt sind
• eine Tankfüllstandsreaktion den befohlenen Ventilzuständen entspricht
• eine Sequenz bei einer Abschaltung korrekt anhält
• eine Verriegelung die Ausrüstung in den beabsichtigten sicheren Zustand überführt
• PID-Änderungen die Prozessreaktion auf sichtbare, testbare Weise verändern

Warum dies für die Beurteilung der Inbetriebnahme wichtig ist

Inbetriebnahmefehler entstehen oft durch Diskrepanzen zwischen Code-Zustand und Ausrüstungszustand.

Typische Beispiele sind:

• Lauf-Bit wahr, aber keine Rückmeldung
• Ventilbefehl offen, aber Prozessvariable bewegt sich nicht
• Sequenzschritt schreitet voran, ohne dass die physische Bedingung erfüllt ist
• Rücksetzlogik löscht zu früh und erlaubt unbeabsichtigten Wiederanlauf

Ein webbasierter Kontaktplan-Editor allein macht diese Diskrepanzen nicht sehr gut sichtbar. Eine Simulationsumgebung mit E/A-Sichtbarkeit und Ausrüstungsreaktion tut dies. Das ist der praktische Unterschied.

„Simulation-Ready“ bedeutet, dass ein Ingenieur nachweisen kann, dass die Steuerungslogik gegen realistisches Prozessverhalten, abnormale Zustände und Wiederanlaufpfade getestet wurde, bevor ein reales System berührt wird. Es ist eine Definition der Fähigkeit, kein Kompliment.

Operativ kann ein Simulation-Ready-Ingenieur:

• Kontaktplan-Logik erstellen, die an benannte E/A und Prozessbedingungen gebunden ist
• definieren, was „korrektes“ Verhalten vor dem Testen bedeutet
• einen realistischen Fehler einspeisen und die Reaktion beobachten
• die Diskrepanz zwischen beabsichtigtem und tatsächlichem Verhalten identifizieren
• die Logik überarbeiten
• das Szenario erneut ausführen und das Ergebnis dokumentieren

Das ist näher an der Inbetriebnahme-Praxis als an theoretischen Syntax-Übungen. Syntax ist wichtig. Die Einsatzfähigkeit ist wichtiger.

Der erforderliche ingenieurtechnische Nachweis

Wenn Sie Ihre Fähigkeiten glaubwürdig demonstrieren wollen, erstellen Sie ein kompaktes Paket an ingenieurtechnischen Nachweisen statt einer Screenshot-Galerie.

Verwenden Sie diese Struktur:

Dokumentieren Sie die eingeführte abnormale Bedingung: Sensorausfall, Not-Halt, Überlast, Rückmeldungsfehler, analoger Ausschlag.

Dieses Format ist nützlich, weil es widerspiegelt, wie echte technische Überprüfungen funktionieren: Systemabsicht, Testbedingung, beobachtetes Ergebnis, Korrekturmaßnahme. Die Screenshots können mitkommen, wenn sie sich benehmen.

1. Systembeschreibung Definieren Sie die Maschine oder Prozesseinheit, ihr Steuerungsziel und den Betriebskontext.
2. Operative Definition von „korrekt“ Geben Sie das exakt erwartete Verhalten im Normalbetrieb und bei Fehlern an.
3. Kontaktplan-Logik und simulierter Ausrüstungszustand Zeigen Sie die Logik des Strompfads und den entsprechenden Ausrüstungs- oder Prozesszustand in der Simulation.
4. Der eingespeiste Fehlerfall
5. Die vorgenommene Überarbeitung Zeichnen Sie die Logikänderung auf, die das Verhalten korrigiert hat.
6. Gelernte Lektionen Erklären Sie, was die ursprüngliche Logik übersehen hat und was die überarbeitete Version nun beweist.

Die Validierung sollte das Verhalten testen, nicht nur das Aussehen des Strompfads. Die Frage ist nicht, ob die Logik kompiliert. Die Frage ist, ob der Prozess unter dem definierten Fehler in den erforderlichen sicheren Zustand übergeht.

Minimale Validierungsprüfungen für diskretes sicherheitsbezogenes Steuerungsverhalten

Für Not-Halt- und verriegelungsnahe Logik verifizieren Sie mindestens:

• Verlust des „In Ordnung“-Signals unterbricht den betroffenen Befehl
• Wiederherstellung des „In Ordnung“-Signals löst keinen automatischen Wiederanlauf aus
• Manuelles Rücksetzen ist erforderlich, wo spezifiziert
• Störungsanzeige ist sichtbar und wie beabsichtigt verriegelt
• Rücksetzen ist gesperrt, bis die Bedingungen für die Rückkehr in den sicheren Zustand erfüllt sind
• Sequenzschritt-Logik umgeht nicht den Abschaltpfad
• Rückmeldungsfehler werden erkannt, wo erforderlich

Minimale Validierungsprüfungen für das PID-Begrenzungsverhalten

Für analoge Regelung verifizieren Sie mindestens:

• Ausgang bleibt innerhalb der definierten Min/Max-Grenzen
• Reglerverhalten bei Sättigung ist beobachtbar
• Integralanteil integriert nicht weiter tiefer in die Sättigung ohne Stellautorität
• Erholung nach Sättigung ist stabil und begrenzt
• Alarm- und Abschalt-Schwellenwerte bleiben kohärent mit den Begrenzungsgrenzen

Hinweis zu Normen

IEC 61511 bietet einen prozesssicherheitstechnischen Rahmen für die Definition von Sicherheitsfunktionen, erforderlichen Aktionen und Lebenszyklusdisziplin in der Prozessindustrie. IEC 60204-1 und NFPA 79 definieren die Erwartungen an die elektrische Sicherheit von Maschinen, einschließlich Stopp- und Wiederanlaufverhalten. Keine dieser Normen wird durch Optimismus erfüllt, und keine wird durch einen Simulator ersetzt. Ein Simulator ist eine Probenumgebung. Das ist gerade deshalb wertvoll, weil er begrenzt ist.

Defensive SPS-Programmierung ist die Disziplin, Steuerungslogik so zu gestalten, dass sie sicher ausfällt, bewusst wieder anläuft und sich vorhersehbar verhält, wenn der Prozess nicht mehr kooperiert. In der Praxis bedeutet das, Freigabebedingungen von Verriegelungen zu trennen, eine Not-Halt-Wiederanlauflogik zu implementieren, die eine manuelle Handlung erfordert, und PID-Ausgänge zu begrenzen, damit analoge Regelkreise nicht über physikalische oder prozessuale Grenzen hinaus steuern.

OLLA Lab fügt sich in diesen Workflow als risikobewusste virtuelle Inbetriebnahmeumgebung ein. Es ermöglicht Ingenieuren, E/A-Verhalten, Fehlerbehandlung, Reaktion des digitalen Zwillings und Logiküberarbeitungen vor der Bereitstellung zu testen. Das ist ein glaubwürdiger Anwendungsfall. Es ist keine Abkürzung zur Zertifizierung, kein Löser für funktionale Sicherheit und kein Ersatz für eine ordnungsgemäße Designprüfung.

- NFPA 79: Electrical Standard for Industrial Machinery - IEC 60204-1 standard page - IEC 61511 Functional safety for the process industry sector - ISA resources on safety instrumented systems - Åström & Hägglund, Advanced PID Control (ISA)