Vorbereitung von SPS-Logik auf Audits zur systematischen Eignung nach IEC 61508 Edition 3

Um SPS-Logik auf Audits zur systematischen Eignung gemäß IEC 61508 Edition 3 vorzubereiten, benötigen Ingenieure Verhaltensnachweise, die belegen, dass die Software unter definierten Fehlerbedingungen deterministisch und sicher reagiert. Eine Simulationsumgebung wie OLLA Lab kann als begrenzte Verifizierungs-Sandbox genutzt werden, um Sicherheitseigenschaften zu testen, die Fehlerbehandlung zu dokumentieren und die Logik vor dem formellen Audit und der physischen Validierung zu härten.

Softwaresicherheit nach IEC 61508 ist nicht primär eine Frage der sauberen Code-Struktur. Es geht darum, ob nachgewiesen werden kann, dass sich die Logik korrekt, wiederholbar und sicher verhält, wenn der Prozess den Normalbetrieb verlässt.

Diese Unterscheidung ist in Edition 3 von größerer Bedeutung, da die Beweislast für das systematische Softwareverhalten eher verschärft als gelockert wird. Die Hardware-Fehleranalyse konzentriert sich weiterhin auf probabilistische Fehlermaße wie PFD und PFH. Software versagt nicht, weil sie im Schaltschrank altert; sie versagt systematisch durch Designfehler, Spezifikationslücken, unbeabsichtigte Interaktionen und ungetestete Grenzfälle.

Ein aktueller interner Benchmark von Ampergon Vallis stützt diesen Punkt. Bei einer internen Analyse von 500 simulierten Testfällen für sicherheitsgerichtete Funktionen (SIF) in OLLA Lab fielen 68 % der ersten Logikentwürfe bei einer Robustheitsprüfung durch, wenn sie analogem Drift, veralteten Eingabewerten oder erzwungenen Werten außerhalb des Bereichs ausgesetzt wurden [Methodik: n=500 simulierte SIF-Validierungsaufgaben über Pumpen-, Förderband-, HLK- und Prozess-Skid-Szenarien; Basisvergleich = erster Entwurf vor Überarbeitung; Zeitfenster = Jan-Feb 2026]. Dies stützt die Aussage, dass Logikentwürfe im ersten Durchgang häufig die Behandlung von anormalen Zuständen vernachlässigen. Es stützt keine Aussage über branchenweite Fehlerraten oder formelle Compliance-Ergebnisse.

Die praktische Änderung liegt in einer stärkeren Betonung des Nachweises der systematischen Eignung (Systematic Capability) durch reproduzierbare Belege, anstatt lediglich die Einhaltung eines Lebenszyklus zu behaupten.

IEC 61508 hat Software schon immer anders behandelt als Hardware, da Softwarefehler systematisch und nicht zufällig sind. In der Praxis bedeutet dies, dass sich Diskussionen in Edition 3 darauf konzentrieren, ob der Entwicklungs- und Verifizierungsprozess nachweisen kann, dass Software-Sicherheitsanforderungen in kontrolliertes, testbares Verhalten übersetzt wurden. „Wir haben den Code sorgfältig geprüft“ ist keine nutzlose Aussage, aber sie ist nicht mehr ausreichend.

Eine zweite Änderung ist die zunehmende Erwartung, dass die Software-Absicherung mit angrenzenden Bereichen wie Cybersicherheit, Konfigurationskontrolle und Disziplin in der Toolchain integriert wird. Das lässt IEC 61508 nicht mit IEC 62443 verschmelzen, aber die Trennung ist nicht mehr so komfortabel, wie es sich manche Teams wünschen würden.

### Erwartungen an Software: Edition 2 vs. Edition 3

| Thema | Schwerpunkt Edition 2 | Entwicklungsrichtung Edition 3 | |---|---|---| | Software-Absicherung | Einhaltung des Lebenszyklus, Prüfdisziplin, strukturelle Tests | Stärkere Verhaltensnachweise, reproduzierbare Verifizierung, maschinell testbare Beweise, wo möglich | | Fehlerbehandlung | Oft in narrativer Form dokumentiert | Zunehmender Druck auf explizite Tests anormaler Zustände und nachvollziehbare Ergebnisse | | Tool-Unterstützung | Hilfreich, aber nicht zentral | Wichtiger, wo Tools Wiederholbarkeit, Rückverfolgbarkeit und Testabdeckung verbessern | | Cybersicherheit | Oft separat behandelt | Explizitere Interaktion mit sicherer Entwicklung und Systemintegrität | | Nachweis der systematischen Eignung | Prozesslastige Demonstration | Prozess plus beobachtbarer Beweis, dass sich die Logik unter definierten Grenzfällen sicher verhält |

Die wichtige Korrektur lautet: Edition 3 bedeutet nicht, dass Software jetzt eine magische Formel wie Hardware erhält. Es bedeutet, dass Software-Ansprüche durch stärkere Beweise untermauert werden müssen.

Systematische Eignung (Systematic Capability) ist die nachgewiesene Fähigkeit des Entwicklungsprozesses und der resultierenden Logik, systematische Fehler zu vermeiden, zu erkennen und zu beherrschen, und zwar in dem für die angestrebte Sicherheitsfunktion erforderlichen Maß.

Für SPS-Ingenieure wird diese Definition konkret, wenn sie in beobachtbare Verhaltensweisen übersetzt wird:

• Die Sicherheitslogik wird auf vorhersagbare und begrenzte Weise ausgeführt.
• Zustandsübergänge sind explizit und wiederherstellbar.
• Fehler führen das System in einen definierten sicheren Zustand.
• Nicht-sicherheitsrelevante Logik beeinträchtigt oder verzögert das Sicherheitsverhalten nicht.
• Testnachweise sind reproduzierbar und auf Anforderungen rückführbar.

Hier wird der Kontrast zwischen Syntax und Einsatzfähigkeit deutlich. Ein Netzwerk kann syntaktisch korrekt sein und dennoch bei der Inbetriebnahme unsicher sein.

Systematische Eignung ist zudem kein Produkt-Gütesiegel. Sie wird nicht durch die Verwendung eines Simulators, eines Codegenerators oder eines KI-Assistenten verliehen. Sie wird durch disziplinierte Spezifikation, Implementierung, Verifizierung, Dokumentation und abschließende Validierung im realen Absicherungsworkflow etabliert.

Die genaue Gruppierung kann je nach Methodik variieren, aber ein praktischer Satz von Softwaresicherheitseigenschaften, der in der fortgeschrittenen funktionalen Sicherheit verwendet wird, umfasst die folgenden Verhaltensweisen, die Ingenieure testen und erklären können müssen.

Die 16 Sicherheitseigenschaften in operativen Begriffen

• Vollständigkeit — Jeder erforderliche Betriebsmodus, Übergang, Abschaltpfad und Wiederherstellungspfad ist definiert.
• Korrektheit — Die implementierte Logik entspricht der festgelegten Sicherheitsanforderung und Steuerungsphilosophie.
• Konsistenz — Tags, Zustände, Übergänge und Verriegelungen verhalten sich im gesamten Programm einheitlich.
• Determinismus — Dieselben Eingaben unter denselben Bedingungen erzeugen dieselben Ausgaben innerhalb der erforderlichen Ausführungsgrenzen.
• Robustheit — Die Logik verarbeitet fehlerhafte, verrauschte, veraltete, fehlende oder außerhalb des Bereichs liegende Eingaben ohne unsicheres Verhalten.
• Freiheit von Beeinflussung — Nicht-sicherheitsrelevante Aufgaben, HMI-Aktionen, Diagnosen oder Hilfslogik verändern das Sicherheitsverhalten nicht unzulässig.
• Rückverfolgbarkeit — Anforderungen, Netzwerke, Tags, Tests und Ergebnisse können ohne Rätselraten verknüpft werden.
• Verifizierbarkeit — Die Codestruktur ermöglicht unabhängige Tests und eine klare Bestanden/Nicht-Bestanden-Bewertung.
• Wartbarkeit — Zukünftige Änderungen können vorgenommen werden, ohne versteckte Sicherheitsregressionen zu erzeugen.
• Einfachheit — Das Design vermeidet unnötige Komplexität, die die Absicht verschleiert oder das Fehlerrisiko erhöht.
• Defensivität — Die Logik antizipiert ungültige Zustände und behandelt diese explizit.
• Wiederherstellbarkeit — Nach einem Fehler kehrt das System nur durch kontrollierte und definierte Rücksetzbedingungen zurück.
• Begrenztheit — Timer, Zähler, analoge Skalierung und Zustandsübergänge bleiben innerhalb bekannter Grenzen.
• Beobachtbarkeit — Interne Zustände und Entscheidungspunkte können während der Verifizierung inspiziert werden.
• Ausfallsicheres Verhalten — Signalverlust, Diskrepanz oder ungültiger Prozesszustand führen bei Bedarf zu einer sicheren Reaktion.
• Testbarkeit — Ingenieure können Bedingungen injizieren und erwartete Ergebnisse ohne Mehrdeutigkeit bestätigen.

Die fünf Eigenschaften, die SPS-Teams meist unterschätzen

- Determinismus: Das Scan-Verhalten muss unter allen relevanten Eingangskombinationen vorhersagbar bleiben. - Robustheit: Analoges Drift, prellende Kontakte und veraltete Kommunikationswerte dürfen nicht zu einer unsicheren Zustandserhaltung führen. - Vollständigkeit: Jeder Zustandsautomaten-Übergang benötigt eine Eintrittsbedingung und eine sichere Austrittsbedingung. - Freiheit von Beeinflussung: Anzeigelogik, Messaging und Komfortfunktionen dürfen die Sicherheitsausführung nicht stören. - Verifizierbarkeit: Wenn die Architektur nicht sauber getestet werden kann, beginnt das Audit-Problem bereits vor dem Standort-Problem.

Dies sind ingenieurtechnische Verhaltensweisen. Wenn ein Team diese unter kontrollierten Testbedingungen nicht demonstrieren kann, wird die Audit-Diskussion interpretativer, als sie sein sollte.

„Simulationsbereitschaft“ (Simulation-Ready) sollte operativ und nicht dekorativ definiert werden.

Ein simulationsbereiter Ingenieur ist in der Lage, Steuerungslogik vor Erreichen eines Live-Prozesses zu beweisen, zu beobachten, zu diagnostizieren und gegen realistisches Prozessverhalten zu härten. Das umfasst mehr als das Schreiben von Kontaktplan-Syntax. Es beinhaltet:

• das Mapping von E/A auf das beabsichtigte Anlagenverhalten,
• die Definition dessen, was „korrekt“ bedeutet, vor dem Testen,
• das Erzwingen normaler und anormaler Bedingungen,
• das Nachverfolgen von Ursache und Wirkung durch Tags und Zustände,
• die Identifizierung von Fehlermodi,
• die Überarbeitung der Logik nach einem Fehler,
• und den Vergleich des simulierten Anlagenzustands mit dem SPS-Zustand.

Dies ist der Unterschied zwischen dem Zeichnen von Netzwerken und dem Proben der Inbetriebnahme-Entscheidungsfindung.

Virtuelle Simulation validiert den Determinismus, indem sie das Ausführungsverhalten unter wiederholbaren Bedingungen beobachtbar macht.

In einer begrenzten Simulationsumgebung können Ingenieure Logik ausführen, Bedingungen konstant halten, Eingänge in kontrollierten Sequenzen umschalten und beobachten, ob Ausgänge und interne Zustände exakt wie beabsichtigt wechseln. Der Punkt ist die Wiederholbarkeit.

Mit OLLA Lab kann dieser Verifizierungs-Workflow Folgendes umfassen:

• Ausführen von Kontaktplan-Logik im Simulationsmodus ohne physische Hardware,
• Umschalten diskreter Eingänge und Erzwingen analoger Werte,
• Überwachen des Tag-Zustands über das Variablen-Panel,
• Vergleichen des Netzwerkverhaltens mit Szenariozielen und Anlagenreaktion,
• und Wiederholen desselben Tests nach jeder Überarbeitung.

Für Determinismus-Prüfungen sollten Ingenieure mindestens diese Fälle testen:

• identische Eingangssequenzen, die mehrfach wiederholt werden,
• asynchrone Eingangsänderungen nahe an Übergangsgrenzen,
• timerabhängige Übergänge,
• Rücksetz- und Neustartverhalten,
• Verlust und Wiederherstellung von Freigaben,
• analoge Schwellenwertüberschreitungen mit Rauschen oder Drift.

Ein häufiges Missverständnis ist, dass Simulation nur grundlegende Funktionalität beweist. Richtig eingesetzt, kann sie auch zeigen, ob die Logik stabile Verhaltensgrenzen aufweist.

OLLA Lab sollte als risikobegrenzte Verifizierungs-Sandbox positioniert werden, nicht als Zertifizierungs-Engine.

Der operative Wert ist direkt: Ingenieure können Kontaktplan-Logik in einem webbasierten Editor erstellen, in der Simulation ausführen, Variablen und E/A-Verhalten inspizieren und die Logik gegen szenariobasierte Maschinenmodelle und digitale Zwillinge validieren, bevor die physische Inbetriebnahme erfolgt. Das macht es nützlich für die Härtung vor dem Audit, Fehlerproben und die Beweissicherung.

Innerhalb dieser begrenzten Rolle unterstützt OLLA Lab mehrere relevante Verifizierungsaufgaben:

- Kontaktplan-Editor: Erstellen und Überarbeiten von Steuerungslogik mit Standard-Befehlstypen, einschließlich Timern, Zählern, Komparatoren, Mathematik, Logik und PID. - Simulationsmodus: Sicheres Ausführen von Logik, Stoppen und erneutes Ausführen von Tests sowie Erzwingen von Eingangsbedingungen ohne Hardware-Exposition. - Variablen-Panel und E/A-Sichtbarkeit: Inspizieren von Tags, Ausgängen, analogen Werten und Schleifenverhalten bei gleichzeitiger Rückverfolgung von Ursache und Wirkung. - 3D/WebXR/VR-Szenarien: Vergleichen des Logikverhaltens mit der Maschinen- oder Prozessreaktion in realistischen Betriebskontexten. - Validierung digitaler Zwillinge: Testen, ob die beabsichtigte Sequenz tatsächlich korrekt gegenüber einem virtuellen Anlagenmodell reagiert. - Szenariobasierte Inbetriebnahme-Übung: Proben von Verriegelungen, Alarmen, Rückmeldungen, Abschaltungen, Freigaben und Rücksetzlogik. - GeniAI-Laborleitfaden: Bereitstellung geführter Unterstützung und Hilfe bei der Logikerstellung während des Lernens und der Testvorbereitung.

Der letzte Punkt benötigt eine Grenze. KI-Unterstützung kann das Entwerfen und Erklären beschleunigen. Sie ersetzt jedoch keine deterministische Überprüfung, unabhängige Verifizierung oder Sicherheitsbeurteilung.

Die Validierung digitaler Zwillinge bedeutet, Steuerungslogik gegen eine virtuelle Repräsentation von Anlagen- oder Prozessverhalten zu testen, um zu bestätigen, dass die Entscheidungen der Logik die beabsichtigte Systemreaktion erzeugen.

Bei sicherheitsrelevanter Arbeit bedeutet das, Fragen zu stellen wie:

• Erzwingt eine Abschaltbedingung den erwarteten sicheren Zustand?
• Verhält sich ein Timeout der Rückmeldung korrekt?
• Bleibt ein manuelles Rücksetzen blockiert, bis alle Freigaben gesund sind?
• Verhindert die analoge Fehlerbehandlung einen falschen Neustart oder eine versteckte unsichere Fortsetzung?
• Erholt sich die Sequenz sauber nach einem anormalen Stopp?

Hier wird OLLA Lab operativ nützlich. Die Szenariostruktur, die E/A-Sichtbarkeit und das Framing durch digitale Zwillinge der Plattform ermöglichen es Ingenieuren, Verhalten zu testen, anstatt nur Syntax zu inspizieren.

Dennoch ist die Validierung digitaler Zwillinge kein Ersatz für die endgültige Abnahme vor Ort, die Gerätevalidierung oder zertifizierte Aktivitäten des Sicherheitslebenszyklus. Es ist eine Beweisebene vor der Inbetriebnahme.

Ingenieure sollten die Fehlerfälle testen, die versteckte Annahmen in der Logik aufdecken, insbesondere dort, wo Zustandserhaltung, Freigaben und analoge Interpretation unbemerkt versagen können.

Ein nützlicher Satz von Fehlern vor dem Audit umfasst:

- Sensor außerhalb des Bereichs: niedrige, hohe, NaN-äquivalente oder unplausible Werte - Analoges Drift: allmähliche Bewegung über Alarm- und Abschaltgrenzwerte - Prellender diskreter Eingang: wiederholtes Übergangsrauschen an Endschaltern oder Rückmeldungen - Veralteter Eingabewert: Wert eingefroren, während sich Prozessbedingungen ändern sollten - Verlust der Freigabe: Rückmeldung des Motorstarters verloren, Ventilprüfung fehlt, Druck nicht aufgebaut - Netzausfall oder Neustartbedingung: Validierung von remanenten Bits und Startzustand - Missbrauch des manuellen Rücksetzens: Rücksetzen verfügbar, bevor Gefahr beseitigt ist - Sequenzunterbrechung: Stopp oder Abschaltung während eines Übergangs - Kommunikationsausfall-Surrogat: eingefrorener oder ungültiger Status von einem abhängigen Subsystem - Verriegelungsdiskrepanz: Befehl erteilt, während Rückmeldung dem erwarteten Anlagenzustand widerspricht

Diese Tests sind wichtig, da viele gefährliche Ausfälle nicht dramatisch sind. Es sind stille Diskrepanzen zwischen dem, was die Logik glaubt, und dem, was die Anlage tatsächlich tut.

Ein prüfungsreifes Paket sollte ingenieurtechnische Überlegungen und Verhaltensnachweise dokumentieren, nicht nur Screenshots.

Verwenden Sie diese kompakte Struktur für jedes sicherheitsrelevante Szenario oder jede Funktion:

Erfassen Sie die ingenieurtechnische Erkenntnis: versteckte Annahme, fehlende Freigabe, mehrdeutiger Rücksetzpfad, Timing-Problem oder Interferenzrisiko.

1. Systembeschreibung Definieren Sie die Anlage, den Prozesszweck, den Betriebsmodus und die Sicherheitsrolle.
2. Operative Definition von „korrekt“ Geben Sie das exakt erwartete Verhalten an, einschließlich Freigaben, Abschaltungen, Rücksetzbedingungen, Timing und sicherem Zustand.
3. Logik und simulierter Anlagenzustand Zeigen Sie die relevanten Netzwerke, das Tag-Mapping und den in der Simulation verwendeten Anlagen- oder Prozesszustand.
4. Der injizierte Fehlerfall Dokumentieren Sie die eingeführte anormale Bedingung, wie sie erzwungen wurde und warum sie wichtig ist.
5. Die vorgenommene Überarbeitung Zeichnen Sie die Logikänderung, Parameteranpassung oder Korrektur der Zustandsbehandlung auf, die nach dem Test vorgenommen wurde.
6. Gelernte Lektionen

Diese Struktur ist bewusst einfach gehalten. Auditoren und Prüfer bevorzugen in der Regel Nachweise, denen sie ohne interpretative Archäologie folgen können.

Ingenieure können OLLA Lab nutzen, um reproduzierbare Artefakte vor dem Audit zu generieren, indem sie jeden Test mit einem Szenario, einem Satz erzwungenen Bedingungen, beobachtbarem Tag-Verhalten und einer dokumentierten Überarbeitung verknüpfen.

Ein praktischer Workflow sieht so aus:

1. Wählen Sie ein Szenario mit expliziten Betriebszielen Zum Beispiel eine Not-Halt-Kette, Pumpensteuerung, Förderbandsequenz oder Freigabegruppe für Lüftungsanlagen.
2. Definieren Sie das erwartete sichere Verhalten vor dem Testen Geben Sie an, was bei Abschaltung, Rücksetzen und anormaler Eingabe geschehen muss.
3. Führen Sie die Logik im Simulationsmodus aus Verwenden Sie den Editor und die Simulationssteuerungen, um die Logik zuerst unter normalen Bedingungen auszuführen.
4. Erzwingen Sie den Fehler über das Variablen-Panel Injizieren Sie analoge Werte außerhalb des Bereichs, entfernen Sie Rückmeldungen, schalten Sie Verriegelungen um oder simulieren Sie veraltete Zustände.
5. Beobachten und dokumentieren Sie die Reaktion Bestätigen Sie, ob sich Ausgänge, Zustände, Alarme und Rücksetzpfade wie definiert verhalten.
6. Überarbeiten Sie die Logik und führen Sie den exakten Fall erneut aus Dies ist der wichtige Teil. Nachweise ohne Revisionshistorie sind oft nur ein Tagebuch.
7. Erfassen Sie die Szenarioparameter und die Zusammenfassung der Ergebnisse Bewahren Sie die Testbedingungen auf, damit ein anderer Prüfer das Ergebnis reproduzieren kann.

In diesem Workflow liegt der Wert von OLLA Lab nicht darin, dass es die Compliance von alleine beweist. Der Wert liegt darin, dass es Ingenieuren hilft, einen wiederholbaren Korpus an Verhaltensnachweisen zu erstellen, bevor die formelle Audit-Einreichung erfolgt und bevor die Live-Anlage zum Teststand wird.

Eine defensive Not-Halt-Implementierung sollte ein ausfallsicheres Verlustverhalten, ein explizites manuelles Rücksetzen und Schutz gegen überbrückte oder vorzeitige Neustartbedingungen erzwingen.

[Sprache: Kontaktplan - IEC 61131-3]

|----[/] E_STOP_OK ----+-------------------------------( ) SAFE_TRIP_ACTIVE | | |----[/] SAFETY_RELAY_FB-+

|----[ ] E_STOP_OK ----[ ] SAFETY_RELAY_FB ----[ ] RESET_PB ----[/] SAFE_TRIP_ACTIVE ----[TON ANTI_TIEDOWN 500ms] |------------------------------------------------------------------------------------------------------------( ) RESET_PERMISSIVE

|----[ ] RESET_PERMISSIVE ----[ ] ALL_PERMISSIVES_OK ----[ ] NO_ACTIVE_FAULTS ----[/] START_INHIBIT ----( ) SAFETY_ENABLE

|----[/] SAFETY_ENABLE ------------------------------------------------------------------------------------( ) MOTOR_RUN_CMD

Warum dieses Muster wichtig ist

- Vollständigkeit: Ein Neustart erfordert definierte gesunde Bedingungen, nicht nur die Wiederherstellung des Not-Halts. - Robustheit: Verlust der Sicherheitsrelais-Rückmeldung oder des Not-Halt-Status erzwingt Abschaltverhalten. - Wiederherstellbarkeit: Das Rücksetzen ist manuell und konditioniert. - Ausfallsicheres Verhalten: Das Fehlen gesunder Sicherheitseingänge entfernt die Freigabe. - Freiheit von Beeinflussung: Der Sicherheitspfad ist explizit und von der Komfortlogik trennbar.

In der Praxis hängt die exakte Implementierung von der Plattform, der Sicherheitsarchitektur und dem zertifizierten Hardwarepfad ab. Der Punkt hier ist strukturell: Sichere Wiederherstellung sollte verdient, nicht vorausgesetzt werden.

3D- und VR-Simulationen helfen, wenn sie die Beobachtbarkeit von Prozesskonsequenzen verbessern, nicht wenn sie lediglich visuelles Theater hinzufügen.

In OLLA Lab können 3D/WebXR/VR-Szenarien Ingenieuren helfen, den Logikzustand mit der sichtbaren Anlagenreaktion zu vergleichen. Das ist nützlich beim Testen von:

• Sequenzfortschritt,
• Aktor-Timing,
• Abhängigkeiten von Rückmeldungen,
• Alarmbedingungen,
• verriegelter Bewegung,
• und Konsequenzen des manuellen Rücksetzens.

Der ingenieurtechnische Vorteil ist, dass Logikfehler leichter zu erkennen sind, wenn die virtuelle Anlage aus einem nachvollziehbaren Grund etwas offensichtlich Falsches tut.

Dennoch bleibt der Nachweis softwareseitig und simulationsbegrenzt. Er stärkt die Verifizierung vor der Inbetriebnahme. Er ersetzt nicht die physische Validierung, das zertifizierte Geräteverhalten oder den formellen Sicherheitsnachweis.

Teams sollten KI-Unterstützung zur Beschleunigung auf der Entwurfs- und Erklärungsebene nutzen und dann eine deterministische menschliche Überprüfung auf der Entscheidungsebene anwenden.

In OLLA Lab kann GeniAI beim Onboarding, der Netzwerkerklärung, korrigierenden Vorschlägen und der Unterstützung bei der Logikerstellung helfen. Das ist nützlich, insbesondere für strukturiertes Lernen und Iteration in frühen Phasen. Es reduziert Reibung, aber Reibungsverringerung ist nicht dasselbe wie Sicherheitsabsicherung.

Für sicherheitsrelevante Logik sollten Teams Folgendes fordern:

• explizites Anforderungs-Mapping,
• unabhängige Überprüfung der generierten Logik,
• fehlerinjizierte Simulation,
• dokumentierte Überarbeitung nach fehlgeschlagenen Fällen,
• und abschließende Genehmigung durch einen qualifizierten Ingenieur innerhalb des Sicherheitslebenszyklus des Projekts.

Der einprägsame Kontrast ist einfach: Entwurfsgenerierung versus deterministisches Veto. Letzteres ist die Aufgabe.

Ingenieure sollten damit beginnen, abstrakte Sicherheitsbehauptungen in reproduzierbare Testfälle umzuwandeln.

Eine praktische Sequenz ist:

• Identifizierung der sicherheitsrelevanten Funktionen im SPS-Umfang,
• Definition des korrekten Verhaltens für normale, Abschalt-, Rücksetz- und anormale Zustände,
• Mapping jeder Funktion auf einen kleinen Satz von Sicherheitseigenschaften,
• Ausführen von fehlerinjizierter Simulation vor dem Hardware-Test,
• Dokumentation von Überarbeitungen in einem kompakten Nachweispaket,
• und Reservierung der Live-Inbetriebnahme für die Validierung, nicht für die erste Entdeckung.

Wenn Ihr aktueller Workflow das Testen anormaler Zustände immer noch als etwas behandelt, das erst passiert, wenn der Schaltschrank unter Spannung steht, ist der Prozess zu spät.

_Bild-Alt-Text: Screenshot des OLLA Lab Variablen-Panels zur Demonstration eines Tests der systematischen Eignung. Ein analoger Eingang wird außerhalb des Bereichs erzwungen, und die Logik wechselt in einen sicheren Zustand, was die Robustheitseigenschaft in einem simulierten IEC 61508-Audit-Workflow veranschaulicht._

- IEC 61131-3: Programmierbare Steuerungen — Teil 3: Programmiersprachen - IEC 61508 Übersicht (funktionale Sicherheit) - NIST AI Risk Management Framework (AI RMF 1.0) - Digital Twin in Manufacturing: A Categorical Literature Review and Classification (IFAC, DOI) - Digital Twin in Industry: State-of-the-Art (IEEE, DOI)

Das Team von OLLA Lab entwickelt Werkzeuge für die nächste Generation der industriellen Automatisierung, mit einem Fokus auf Verifizierbarkeit, digitale Zwillinge und die systematische Absicherung von SPS-Logik.

Dieser Artikel wurde auf Basis der Anforderungen der IEC 61508 Edition 3 und gängiger Praktiken der funktionalen Sicherheit erstellt. Die genannten Benchmarks und methodischen Empfehlungen spiegeln interne Analysen von Ampergon Vallis wider und dienen als Leitfaden für Ingenieure, ersetzen jedoch keine formelle Zertifizierung oder projektspezifische Sicherheitsbewertung.