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

Die korrekte Programmierung von Not-Halt-Einrichtungen und Sicherheitsverriegelungen erfordert einen defensiven SPS-Designansatz: Hardware-Sicherheitsfunktionen müssen gefahrbringende Energie abschalten, während die Standard-SPS-Logik deterministisch reagieren, Laufzustände beenden und unerwartete Neustarts verhindern muss. OLLA Lab bietet eine begrenzte Simulationsumgebung zur Validierung dieser Verhaltensweisen bei anormalen Zuständen vor der Inbetriebnahme.

Ein häufiges Missverständnis ist, dass „die Programmierung des Not-Halt“ bedeutet, dass die SPS die Sicherheitsfunktion ausführt. Das ist nicht der Fall. Nach anerkannter Maschinensicherheitspraxis muss die Not-Halt-Funktion durch entsprechend ausgelegte Sicherheitshardware oder sicherheitsgerichtete Steuerungssysteme implementiert werden, während die Standard-SPS-Logik diesen Sicherheitsstatus typischerweise überwacht und durch das Zurücksetzen von Software-Laufbefehlen, Alarmen und Neustartpfaden reagiert.

Die praktische Lücke liegt nicht in der Syntax, sondern im Fehlerverhalten. Ein Programm eines Anfängers beweist oft nur, dass eine Maschine starten kann; ein defensives Programm beweist, was passiert, wenn ein Draht bricht, ein Signal ausbleibt oder ein Bediener den Not-Halt zurücksetzt.

Ampergon Vallis Kennzahl: In einer internen Überprüfung von 5.000 nutzerseitig eingereichten Kontaktplan-Projekten in OLLA Lab-Förderbandszenarien scheiterten 68 % der ersten Einreichungen daran, den Motorlaufzustand nach einem simulierten Not-Halt-Reset so lange unterbrochen zu halten, bis ein bewusster Neustartbefehl erteilt wurde. Methodik: n=5.000 Ersteinreichungen von Studierenden bei Förderband-Stopp/Start-Aufgaben; Basis-Vergleichswert = erwartetes Verhalten ohne automatischen Neustart nach Wiederherstellung des Sicherheitszustands; Zeitfenster = 1. Januar 2025 bis 28. Februar 2026. Dies stützt eine spezifische Aussage über häufige Ausbildungsfehler in der Neustart-Logik. Es misst keine Vorfallraten im Feld, keine Anlagensicherheit oder die allgemeine Kompetenz der Belegschaft.

Defensive Programmierung in der industriellen Automatisierung bedeutet, Kontaktplan-Logik unter der Annahme zu entwerfen, dass Geräte ausfallen, Bediener in der falschen Reihenfolge handeln und Prozessrückmeldungen manchmal fehlen, verspätet oder falsch sind. Das ist die normale Designgrundlage, kein Pessimismus. Anlagen finden sehr zuverlässig genau den Zweig, den Sie nicht getestet haben.

In der SPS-Programmierung ist defensive Programmierung der Unterschied zwischen Bewegung ermöglichen und Betrieb unter anormalen Bedingungen kontrollierbar machen. Ersteres ist leicht zu demonstrieren. Letzteres ist das, was die Inbetriebnahme überlebt.

Ein defensives Steuerprogramm enthält üblicherweise:

• explizite Freigaben für den Start,
• aktive Verriegelungen zum Stoppen oder Verhindern der Fortsetzung,
• Funktionsprüfungen (Proof-of-Operation),
• Zeitüberwachungen (Timeout-Handling),
• Alarmgenerierung,
• Neustart-Disziplin nach Abschaltungen oder Not-Halt-Ereignissen,
• Zustands-Reset-Logik, die bewusst und nicht implizit erfolgt.

Dies ist auch der Punkt, an dem Simulation-Ready eine präzise Definition benötigt. Im Sprachgebrauch von Ampergon Vallis ist ein Simulation-Ready-Ingenieur nicht jemand, der nur die Syntax des Kontaktplans kennt. Es bedeutet einen Ingenieur, der Steuerungslogik beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten härten kann, bevor sie einen realen Prozess erreicht.

Warum ausfallsicheres Eingangsdesign meist mit Öffner-Logik beginnt

Ausfallsicheres diskretes Design verwendet oft Öffner (NC - Normally Closed) im Feld für kritische Stopp- und Freigabekreise, sodass ein Drahtbruch, Stromausfall oder offener Stromkreis eher zu einem Stopp- als zu einem Laufzustand führt. Das Prinzip ist einfach: Der Fehlerzustand sollte dem sicheren Zustand ähneln.

In Softwarebegriffen bedeutet das oft, dass die SPS ein Statusbit für eine intakte Sicherheitskette nur dann als „gesund“ erkennt, wenn der überwachte Kreis geschlossen ist. Wenn sich der Kreis unerwartet öffnet, fällt das Bit ab. Eine sichere Maschine sollte nicht von der Hoffnung auf Durchgang abhängen.

Dies macht eine Standard-SPS nicht sicherheitsgerichtet. Es macht die Reaktion der Standard-SPS auf die Sicherheitskette jedoch deterministischer und einfacher zu validieren.

Die korrekte Struktur besteht darin, die Sicherheitsfunktion von der Standard-SPS-Reaktion zu trennen. Die Not-Halt-Funktion selbst sollte gefahrbringende Energie über festverdrahtete Sicherheitsrelais, Schütze oder eine Sicherheits-SPS bzw. einen Sicherheitscontroller, der für diesen Zweck ausgelegt ist, abschalten. Die Standard-SPS überwacht dann einen Hilfsstatus dieses Sicherheitspfads und nutzt ihn, um Software-Laufbefehle zurückzusetzen, Verriegelungen zu löschen, Neustarts zu verhindern und Bedienermeldungen auszugeben.

Diese Unterscheidung ist wichtig, da die IEC 61508 die Disziplin des Lebenszyklus der funktionalen Sicherheit adressiert und die ISO 13850 die Not-Halt-Funktion als ergänzende Schutzmaßnahme und nicht als Software-Annehmlichkeit definiert. Wenn Standard-Logik vorgibt, die Sicherheitsebene zu sein, ist das Design bereits in die falsche Richtung gelaufen.

Eine praktische Sequenz für die Standard-SPS-Reaktion

Eine typische Nicht-Sicherheits-SPS-Implementierung führt folgende Schritte aus:

1. Überwachung eines Sicherheitsketten-Statusbits, das von einem Hilfskontakt eines Sicherheitsrelais oder einem äquivalenten Status abgeleitet ist.
2. Reihenschaltung dieses Bits mit der Laufberechtigung, sodass der Softwarepfad sofort zusammenbricht, wenn die Sicherheit verloren geht.
3. Rücksetzen von Selbsthaltungen oder Verriegelungslogik bei Sicherheitsverlust.
4. Erfordernis eines bewussten Neustartbefehls nach dem Reset, anstatt einen automatischen Neustart zu erlauben, wenn der Not-Halt physisch zurückgesetzt wird.
5. Ankündigung der Ursache, damit Bediener und Techniker zwischen Not-Halt, Freigabefehler, Verriegelungsabschaltung und Timeout unterscheiden können.

Beispiel für ein Kontaktplan-Muster für Not-Halt-bewusste Lauflogik

Unten ist ein vereinfachtes Muster für Standard-SPS-Logik, das den Sicherheitszustand widerspiegelt. Es ist illustrativ, kein sicherheitszertifiziertes Design.

Kontaktplan-Muster:

• `StartPB` in Reihe mit `StopPB` und `EStop_OK` aktiviert `RunCmd`.
• `RunCmd` mit `StopPB`, `EStop_OK` und `Permissive_OK` hält einen Selbsthaltepfad wie `Mtr_SealIn` aufrecht.
• `Mtr_SealIn` steuert `Motor_Run`.

Interpretation:

• `EStop_OK` ist nur dann wahr, wenn die überwachte Sicherheitskette intakt ist.
• Wenn `EStop_OK` abfällt, brechen sowohl der Laufpfad als auch der Selbsthaltepfad zusammen.
• Wenn `EStop_OK` nach dem Reset zurückkehrt, startet der Motor nicht automatisch neu, es sei denn, `StartPB` wird erneut betätigt.

Der letzte Punkt ist nicht nur kosmetisch. Die Verhinderung eines unerwarteten Neustarts ist eine der zentralen Verhaltensanforderungen an die Not-Halt-Reaktion.

Was sollte nach einem Not-Halt-Reset geschehen?

Nachdem der Not-Halt zurückgesetzt wurde, sollte die Standard-SPS in einem gestoppten Zustand verbleiben, bis alle erforderlichen Neustartbedingungen erfüllt sind und eine bewusste Startaktion durchgeführt wurde. In vielen Systemen beinhaltet dies:

• Sicherheitskette wiederhergestellt,
• Stopp-Befehl in gesundem Zustand,
• kein aktiver Fehlerzustand,
• Sequenzzustand zurückgesetzt oder quittiert,
• vom Bediener ausgelöster Neustart.

Wenn Ihre Logik neu startet, weil die Verriegelung überlebt hat oder weil die Startbedingung nie gelöscht wurde, ist der Code nicht „fast richtig“. Er ist auf gefährliche Weise falsch.

Eine Freigabe (Permissive) ist eine Bedingung, die wahr sein muss, bevor eine Sequenz starten darf. Eine Verriegelung (Interlock) ist eine Bedingung, die den Betrieb stoppt, hemmt oder unterbricht, wenn ein unsicherer oder ungültiger Laufzustand auftritt. Anfänger vermischen die Begriffe oft, da beide als Kontakte im Kontaktplan erscheinen. Dem Prozess ist das Vokabular egal, aber dem Design-Review nicht.

Freigabe vs. Verriegelung

| Logiktyp | Funktion | Typisches Timing | Beispiel in OLLA Lab | |---|---|---|---| | Freigabe | Vor-Start-Bedingung, die vor Initiierung erfüllt sein muss | Vor Laufbefehl oder Sequenzstart | Tankfüllstand über Minimum vor Pumpenstart | | Verriegelung | Aktive Laufbedingung, die bei Verletzung Stopp, Hemmung oder Abschaltung erzwingt | Während des Betriebs | Hoch-Hoch-Druck am Ausgang löst laufende Pumpe aus | | Freigabe mit Selbsthalte-Relevanz | Muss zum Start wahr sein und manchmal wahr bleiben, je nach Philosophie | Start und ggf. Lauf | Schutztür geschlossen vor Zyklusstart | | Abschalt-Verriegelung | Erzwingt sofortige oder sequenzierte Abschaltung | Während anormalem Zustand | Übertemperatur oder Verlust der Motorüberlast-Rückmeldung |

Eine nützliche Design-Unterscheidung

Freigaben beantworten: „Darf ich starten?“ Verriegelungen beantworten: „Darf ich fortfahren?“

Dieser Kontrast ist kompakt, weil er operativ nützlich ist. Er deckt zudem schlechte Logik schnell auf.

### Beispiel: Pumpensteuerung

Für eine einfache Pumpensequenz:

- Freigabe: Füllstand im Pumpensumpf über dem Low-Low-Schwellenwert. - Freigabe: Motorüberlast nicht ausgelöst. - Verriegelung: Hochdruckschalter am Ausgang öffnet während des Laufs. - Verriegelung: Lauf-Rückmeldung erfolgt nicht innerhalb von 3 Sekunden. - Neustart-Regel: Nach Abschaltung Bediener-Reset und erneuten Start erfordern.

Hier ist die Steuerungsphilosophie wichtiger als die Anzahl der Netzwerke. Ein kurzes Programm kann trotzdem grundlegend falsch sein.

Der sauberste Ansatz ist die Trennung der Logik in verschiedene Ebenen: Startberechtigung, Laufaufrechterhaltung, Abschalterkennung und Reset/Neustart-Disziplin. Das Vermischen in einem dichten Netzwerk spart vertikalen Platz, führt aber zu Klarheitseinbußen. Bildschirme sind billig; Mehrdeutigkeit ist teuer.

Eine praktische Struktur sieht so aus:

1. Startberechtigungsebene

Verwenden Sie ein dediziertes Bit wie `Start_Permissive_OK`, das aus allen erforderlichen Vorbedingungen gebildet wird:

• Not-Halt-Status, überwacht von der Sicherheitshardware,
• Hilfsenergien verfügbar,
• kein aktiver Fehler,
• erforderliche Prozessbedingung vorhanden,
• Moduswahl gültig.

2. Laufaufrechterhaltungsebene

Verwenden Sie ein separates Bit wie `Run_Allowed`, das nur dann wahr bleibt, solange die aktiven Laufbedingungen akzeptabel sind:

• keine Verriegelungsabschaltung,
• kein Stopp-Befehl,
• kein Timeout der Rückmeldung,
• kein Sequenzabbruch.

3. Abschalterkennungsebene

Erstellen Sie explizite Abschalt-Bits, anstatt die Ursachen in einem Lauf-Netzwerk zu vergraben:

• `Trip_HighPressure`
• `Trip_ProofFail`
• `Trip_Overtemp`
• `Trip_EStopObserved`

Dies verbessert die Diagnose, HMI-Meldungen und die Analyse nach Fehlern.

4. Reset- und Neustart-Disziplin

Erfordern Sie einen manuellen Reset, wo angebracht, und danach einen neuen Startbefehl. Der Reset sollte den Fehlerzustand löschen; er sollte nicht stillschweigend eine Bewegung auslösen.

Diese Unterscheidung ist scharf zu halten: Reset ist nicht Neustart.

Fehlerbehandlung kann nicht auf dem „Happy Path“ validiert werden. Sie müssen den Fehler injizieren, den Zustandsübergang beobachten und die Logik überarbeiten, wenn die Reaktion falsch ist. Das ist die gesamte Übung.

Hier wird OLLA Lab operativ nützlich. Sein browserbasierter Kontaktplan-Editor, der Simulationsmodus, die Sichtbarkeit von Variablen und die szenariobasierten Gerätemodelle ermöglichen es Ingenieuren, anormale Bedingungen zu testen, ohne unter Spannung stehende Geräte zu berühren.

Was OLLA Lab in diesem Workflow leistet

OLLA Lab sollte hier vorsichtig positioniert werden. Es ersetzt nicht die Inbetriebnahme vor Ort, die Sicherheitsvalidierung oder eine formale Bewertung der funktionalen Sicherheit. Es bietet eine risikokontrollierte Übungsumgebung für Aufgaben, die zu gefährlich, zu störend oder zu teuer sind, um sie beiläufig an realen Anlagen zu üben.

In der Praxis ermöglicht die Plattform Benutzern:

• Kontaktplan-Logik in einem webbasierten Editor zu erstellen,
• die Simulation sicher zu starten und zu stoppen,
• Eingänge in Echtzeit zu schalten und Ausgänge zu beobachten,
• Variablen, Tags, Analogwerte und Steuerungszustände zu inspizieren,
• das Verhalten des Kontaktplans mit der simulierten Gerätereaktion zu vergleichen,
• innerhalb realistischer industrieller Szenarien mit dokumentierten Gefahren und Inbetriebnahmeanmerkungen zu arbeiten.

Das ist der richtige Anwendungsfall: Übung, Validierung und fehlerbewusste Iteration.

Wie man eine Not-Halt-Reaktion in OLLA Lab testet

Eine nützliche Validierungssequenz in OLLA Lab ist unkompliziert:

5. Bestätigen Sie, dass:

• die Laufspule abfällt,
• die Selbsthaltung abfällt,
• der Ausgangszustand spannungsfrei wird,
• jede Abschalt- oder Alarmanzeige wie erwartet gesetzt wird.

1. Erstellen Sie ein Motor-Start/Stopp-Netzwerk mit einem Selbsthaltezweig.
2. Fügen Sie ein überwachtes `EStop_OK`-Bit in Reihe mit dem Laufpfad ein.
3. Starten Sie die simulierte Maschine.
4. Verwenden Sie im Simulationsmodus das Variablen-Panel, um das überwachte Not-Halt-Statusbit von wahr auf falsch zu setzen.
5. Setzen Sie `EStop_OK` zurück auf wahr.
6. Bestätigen Sie, dass die Maschine gestoppt bleibt, bis ein neuer Startbefehl erteilt wird.

Diese Sequenz lehrt mehr als Syntax. Sie lehrt Neustart-Disziplin und Zustandsbewusstsein.

Warum szenariobasierte Fehlerinjektion wichtig ist

Szenariobasierte Simulation ist wichtig, weil Verriegelungen kontextabhängig sind. Ein Förderband, eine Hebestation, ein Lüftungsgerät und ein Mischer fallen nicht auf die gleiche Weise aus, und sie sollten nicht so programmiert werden, als ob sie es täten.

Die Szenariostruktur von OLLA Lab ist hier nützlich, da sie die Logik verknüpft mit:

• E/A-Mappings,
• Steuerungsphilosophie,
• Gefahren,
• Sequenzanforderungen,
• Analog- oder PID-Bindungen, wo relevant,
• Verifizierungsschritten.

Das macht aus einer Kontaktplan-Übung eine Inbetriebnahmesimulation. Der Unterschied ist nicht subtil.

Korrektes Verhalten sollte operativ definiert werden, bevor die Tests beginnen. „Sieht gut aus“ ist kein Testkriterium.

Für eine Standard-SPS-Reaktion auf ein überwachtes Not-Halt-Ereignis beinhaltet eine brauchbare Definition von „korrekt“ üblicherweise:

• Software-Laufbefehl fällt innerhalb der nächsten Zykluszeit nach Verlust des überwachten Sicherheitsstatus ab,
• verriegelter Laufzustand überlebt das Not-Halt-Ereignis nicht,
• Ausgänge, die von der Standard-Logik gesteuert werden, werden angemessen spannungsfrei geschaltet,
• Alarm- oder Ereigniszustand identifiziert die Stopp-Ursache,
• das Zurücksetzen des physischen Not-Halt-Status allein startet die Bewegung nicht neu,
• Neustart erfordert bewusste Bedieneraktion und jede erforderliche Reset-Sequenz.

Für ein Freigabe- oder Verriegelungsdesign kann korrektes Verhalten auch beinhalten:

• Sequenz kann bei fehlenden Freigaben nicht starten,
• aktive Abschaltung unterbricht den Laufzustand vorhersehbar,
• Timeout der Rückmeldung wird innerhalb des konfigurierten Fensters erkannt,
• Sequenz-Zustandsautomat kehrt nach Abschaltung in einen definierten sicheren Zustand zurück,
• keine versteckte Selbsthaltung oder ein gespeichertes Bit verursacht einen unbeabsichtigten Neustart.

Deshalb sollte Simulation evidenzbasiert sein. Wenn die Akzeptanzkriterien vage sind, wird das Testergebnis ebenfalls vage sein.

Wenn Sie tatsächliches Urteilsvermögen in der Steuerungstechnik demonstrieren wollen, bewahren Sie eine kompakte Sammlung technischer Nachweise auf, anstatt einen Ordner voller Screenshots. Screenshots sind leicht zu sammeln und leicht misszuverstehen.

Verwenden Sie diese Struktur:

Spezifizieren Sie den eingeführten Fehler: Not-Halt-Verlust, Rückmeldungsfehler, Druckabschaltung, unterbrochene Freigabe, klebender Sensor, Timeout oder kommunikationsabhängige Bedingung, falls modelliert.

1. Systembeschreibung Definieren Sie die Maschine oder Prozesszelle, ihr Betriebsziel, die wichtigsten E/A und sicherheitsrelevanten Zustände.
2. Operative Definition von „korrekt“ Geben Sie das exakt erwartete Verhalten für Start, Stopp, Not-Halt-Ereignis, Abschaltung, Reset und Neustart an.
3. Kontaktplan-Logik und simulierter Gerätezustand Erfassen Sie die relevanten Netzwerke, Tag-Zustände und den simulierten Maschinenzustand zum Zeitpunkt des Tests.
4. Der injizierte Fehlerfall
5. Die vorgenommene Korrektur Dokumentieren Sie, was sich in der Logik geändert hat, nachdem der Fehler beobachtet wurde.
6. Gelernte Lektionen Fassen Sie den Designfehler und das korrigierte Prinzip zusammen, wie z. B. „Selbsthaltezweig muss bei Verlust des Sicherheitszustands zusammenbrechen“ oder „Reset-Bit darf nicht gleichzeitig als Neustartbefehl dienen“.

Dieses Paket ist weitaus glaubwürdiger als eine polierte Galerie. Technische Nachweise sollten Verhalten erklären, nicht nur dekorieren.

Die entscheidende Grenze ist, dass Standard-SPS-Kontaktplan-Logik kein Ersatz für eine sicherheitsgerichtete Not-Halt-Implementierung ist. Das ist das erste Prinzip.

Das zweite Prinzip ist, dass Software dennoch wichtig ist, weil sie das deterministische Verhalten der Maschine nach dem Eingreifen der Sicherheitsfunktion steuert. In der Praxis beinhaltet das:

• Zurücksetzen von Software-Laufberechtigungen,
• Löschen des Sequenzzustands, wo erforderlich,
• Verhindern unerwarteter Neustarts,
• Ankündigung der Ursache,
• Unterstützung einer geordneten Wiederherstellung.

Relevante Referenzen sind:

• ISO 13850 für die Not-Halt-Funktion und die Verhinderung unerwarteter Neustarts im Maschinenkontext.
• IEC 61508 für den breiteren Rahmen der funktionalen Sicherheit und das Denken in Lebenszyklen.
• ISO 13849-1 und IEC 62061 können je nach Architektur und erforderlicher Performance-Integrität ebenfalls für das Maschinensicherheitsdesign relevant sein.
• Anleitungen von Organisationen wie exida sind oft nützlich für die praktische Interpretation des Sicherheitslebenszyklus und der Validierungsdisziplin.

Eine letzte Warnung ist notwendig: Simulationsvalidierung ist wertvoll, aber sie begründet für sich allein keine SIL-Eignung, PL-Erreichung, rechtliche Konformität oder Einsatzbereitschaft. Sie verbessert die Logikqualität und die Vorbereitung auf die Inbetriebnahme. Das sind wichtige Vorteile. Sie sind nicht dasselbe wie eine Zertifizierung.

Der Übergang findet statt, wenn Sie nicht mehr nur fragen, ob das Netzwerk syntaktisch korrekt ist, sondern ob die Prozessreaktion bei einem Fehlerfall vertretbar ist. Das ist die eigentliche Schwelle.

Eine Denkweise auf Inbetriebnahme-Niveau beinhaltet üblicherweise diese Gewohnheiten:

• Testen Sie anormale Zustände genauso bewusst wie normale Zustände,
• erzwingen Sie fehlende Rückmeldungen und verzögerte Übergänge,
• verifizieren Sie, dass Selbsthaltungen zusammenbrechen, wenn sie es sollten,
• trennen Sie Reset von Neustart,
• dokumentieren Sie Abschaltursachen explizit,
• vergleichen Sie den Controller-Zustand mit dem simulierten Gerätezustand,
• überarbeiten Sie die Logik basierend auf beobachtetem Fehlerverhalten, nicht auf Intuition.

Das ist der begrenzte Wert von OLLA Lab. Es gibt Ingenieuren einen Ort, um genau die Aufgaben zu üben, die reale Anlagen als Anfängerübungen nur ungern anbieten: Fehler injizieren, Ursache-Wirkungs-Zusammenhänge verfolgen, Neustartverhalten validieren und Logik korrigieren, bevor Hardware involviert ist.

Das ist nicht glamourös. Es ist einfach die Art und Weise, wie kompetente Steuerungstechnik gebaut wird.

Dieses Dokument wurde von den Experten von OLLA Lab und Ampergon Vallis erstellt, um die Lücke zwischen theoretischer SPS-Programmierung und der praktischen, fehlerbewussten Inbetriebnahme zu schließen.

Die in diesem Leitfaden beschriebenen Prinzipien basieren auf gängigen Industriestandards (ISO 13850, IEC 61508) und den internen Validierungsdaten von Ampergon Vallis. Die Simulationsempfehlungen dienen der Ausbildung und Vorbereitung, nicht der Zertifizierung von Sicherheitssystemen.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standard overview - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)