Wie man nachweist, dass KI-generierte Kontaktplan-Logik die Anforderungen der IEC 61508 Teil 3 erfüllt

Um KI-generierte Kontaktplan-Logik (Ladder Logic) gemäß IEC 61508 Teil 3 zu bewerten, sollten Ingenieure deterministisches Verhalten, Fehlerreaktionen und Rückverfolgbarkeit durch Simulation statt nur durch Prompts prüfen. OLLA Lab bietet eine begrenzte Validierungsumgebung, in der Logik gegen realistisches Maschinenverhalten getestet, unter Fehlerbedingungen beobachtet und als prüfungsreifer Ausführungsnachweis dokumentiert werden kann.

KI-generierte Kontaktplan-Logik scheitert bei Audits nicht, weil sie "KI" ist. Sie scheitert, weil funktionale Sicherheit deterministisches, nachvollziehbares und verifizierbares Verhalten erfordert, während die Ausgabe eines LLM probabilistisch ist, bis ein Ingenieur sie einschränkt und verifiziert.

Eine aktuelle interne Analyse von Ampergon Vallis ergab, dass 68 % von 500 KI-generierten Motorsteuerungsroutinen einen Test auf begrenzte Vorhersehbarkeit unter simulierten Sensorverlustbedingungen nicht bestanden, bis sie manuell durch einen Ingenieur eingeschränkt wurden [Methodik: n=500 generierte Motorstart- und Freigabe-/Verriegelungsroutinen getestet in der OLLA Lab-Simulation, Basis-Vergleichswert = deterministische Akzeptanzkriterien abgeleitet aus vordefinierten Sequenz- und Fehlerreaktionserwartungen, Zeitfenster = Januar-März 2026]. Diese Kennzahl stützt einen engen Punkt: Unbeschränkte KI-Ausgaben verletzen in der Simulation häufig ein vorhersehbares Fehlerverhalten. Sie stützt keine Aussage über sämtliche SPS-Codes, alle Anbieter oder formale Zertifizierungsergebnisse.

Diese Unterscheidung ist wichtig. Man kann keinen Prompt auditieren. Man kann nur die deterministische Ausführung der resultierenden Logik unter simulierten physikalischen Bedingungen auditieren. Syntax ist billig; Einsatzfähigkeit ist es nicht.

KI-generierte Logik scheitert bei IEC 61508 Teil 3 Audits, weil sich die Norm mit der systematischen Integrität des Softwareverhaltens befasst und nicht damit, wie schnell der Code erstellt wurde. IEC 61508-3 verlangt, dass Software so spezifiziert, strukturiert, verifiziert und begründet ist, dass sie einen vorhersehbaren Betrieb unter definierten Bedingungen und definierten Fehlern unterstützt.

Der Kernkonflikt ist einfach. LLMs generieren wahrscheinliche nächste Token aus Mustern in Trainingsdaten. Sicherheitssoftware muss unter bekannten Prozessbedingungen begrenzte, erklärbare Zustandsübergänge erzeugen. Das eine ist probabilistische Generierung; das andere ist deterministische Verantwortlichkeit.

Deshalb ist die Prompt-Historie kein Konformitätsnachweis. Ein Prompt mag die Absicht erklären, aber er beweist nicht das Verhalten im Scan-Zyklus, die Fehlerbehandlung, den Übergang in den sicheren Zustand oder die Einhaltung von Zeitvorgaben.

Die praktischen Fehlermodi sind Steuerungsingenieuren bekannt:

• Freigaben, die korrekt anziehen, aber nicht deterministisch abfallen
• Speicherbits (Latches), die anormale Neustartbedingungen ohne explizite Rücksetzlogik überdauern
• Alarmbehandlung, die einen fehlerhaften Wert erkennt, aber keine sichere Reaktion erzwingt
• Analoge Vergleiche ohne Behandlung von Bereichsüberschreitungen
• Schrittkettenlogik, die im Normalfall funktioniert, aber bei asynchronen Eingängen bricht
• Überkomplizierte Kontaktplanstrukturen, die die Verifizierung erschweren

IEC 61508 verwendet unterschiedliche Terminologien für Lebenszyklusaktivitäten, aber die technische Anforderung ist konsistent: Das Softwareverhalten muss begründet, testbar und auf die Sicherheitsabsicht rückführbar sein. KI kann Logik entwerfen. Sie kann keine systematische Eignung durch Enthusiasmus erben.

Hier wird OLLA Lab operativ nützlich. Seine Rolle ist nicht die Zertifizierung von KI-Code. Seine Rolle ist die Bereitstellung einer risikobegrenzten Umgebung, in der Ingenieure die Generierungs-Validierungs-Schleife durchlaufen, das Scan-Verhalten beobachten, Fehler induzieren, den Kontaktplan-Zustand mit dem simulierten Anlagenzustand vergleichen und dokumentieren können, was die Logik tatsächlich tut.

"Simulationsbereit" bedeutet, dass ein Ingenieur die Steuerungslogik vor Erreichen eines realen Prozesses gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann.

Diese Definition ist operativ, nicht aspirational. Ein simulationsbereiter Ingenieur kann:

• definieren, wie korrektes Verhalten aussieht, bevor die Tests beginnen
• Logik gegen ein Maschinen- oder Prozessmodell statt gegen Annahmen testen
• E/A, interne Bits, Analogwerte und den Sequenzzustand während der Ausführung überwachen
• anormale Bedingungen wie Sensorverlust, veraltete Rückmeldungen, Stromausfälle und Freigabeausfälle injizieren
• identifizieren, wo der Kontaktplan-Zustand vom erwarteten Anlagenverhalten abweicht
• Logik überarbeiten und erneut testen, bis das Verhalten begrenzt und erklärbar ist

Dies ist der wahre Unterschied zwischen Kontaktplan-Syntax und Inbetriebnahme-Urteilsvermögen. Viele Leute können einen Kontaktplan zeichnen. Wenige können erklären, warum eine Pumpe einen Neustart nach einem fehlgeschlagenen Nachweis verweigern sollte oder warum eine Freigabe einen Laufbefehl nach einem Fehler bedingungslos abweisen muss.

Die folgenden "16 Säulen" sind eine praktische ingenieurtechnische Synthese, die aus den Erwartungen des Software-Sicherheitslebenszyklus der IEC 61508-3 abgeleitet wurde, insbesondere der Betonung der Norm auf Korrektheit, Verifizierbarkeit, Fehlervermeidung und diszipliniertes Design. Es handelt sich nicht um eine wörtliche Liste aus der Norm. Sie bilden eine Arbeitsstruktur zur Bewertung, ob KI-generierte Kontaktplan-Logik auf prüfbare Strenge zusteuert.

### Gruppe 1: Architektur und Determinismus

Alle definierten Betriebszustände, Startzustände, Abschaltzustände und anormalen Zustände werden behandelt.

• 1. Vollständigkeit

Die Logik entspricht der beabsichtigten Steuerungsphilosophie und den Sicherheitsanforderungen.

• 2. Korrektheit

Das Ausführungsverhalten ist unter gleichen Bedingungen begrenzt und wiederholbar.

• 3. Vorhersehbarkeit

Das Design vermeidet interne Widersprüche, unbeabsichtigte Speicherungen, Deadlock-ähnliche Stillstände und instabile Zustandsinteraktionen.

• 4. Freiheit von intrinsischen Fehlern

Komplexität wird minimiert, damit die Logik überprüfbar und testbar bleibt. KI scheitert hier oft, indem sie kunstvolle Logik produziert, die zwar kompiliert, aber schwer zu rechtfertigen ist.

• 5. Einfachheit

### Gruppe 2: Fehlertoleranz und Reaktion

Die Logik verarbeitet ungültige, verrauschte, fehlende oder außerhalb des Bereichs liegende Eingänge ohne undefiniertes Verhalten.

• 6. Robustheit

Das Programm erkennt aktiv ausgefallene Sensoren, fehlende Nachweissignale, fehlerhafte Analogwerte oder Kommunikationsverluste, wo relevant.

• 7. Fehlererkennung

Gefährliche Ausgänge werden durch deterministische Veto-Logik entfernt, wenn Sicherheitsbedingungen verletzt werden.

• 8. Übergang in den sicheren Zustand

Nicht-kritische Funktionen fallen kontrolliert aus, während wesentliches sicheres Verhalten erhalten bleibt.

• 9. Graceful Degradation (Sanfte Degradierung)

Variablen, remanente Zustände und kritische Werte sind vor unbeabsichtigter Korruption oder Missbrauch geschützt.

• 10. Datenintegrität

Die Logik reagiert innerhalb der erforderlichen Prozesssicherheitszeit und verlässt sich nicht auf unbegrenzte Ausführungsannahmen.

• 11. Zeitliche Einschränkungen

### Gruppe 3: Verifizierung und Rückverfolgbarkeit

Jeder sicherheitsrelevante Kontaktplan-Zweig, jede Verriegelung, jeder Alarm oder jeder Sequenzschritt lässt sich auf eine definierte Anforderung oder Gefahrenkontrolle zurückführen.

• 12. Rückverfolgbarkeit

Funktionen sind so partitioniert, dass sie unabhängig überprüft und getestet werden können.

• 13. Modularität

Die Logik kann unter definierten Szenarien ausgeführt werden und es kann nachgewiesen werden, dass sie die erwarteten Ergebnisse liefert.

• 14. Verifizierbarkeit

Zukünftige Ingenieure können den Code verstehen, Fehler beheben und sicher modifizieren.

• 15. Wartbarkeit

Der Schutz gegen unbefugtes Forcen oder unsichere Modifikation wird berücksichtigt, wo Softwareintegrität mit Cybersicherheitspraktiken (einschließlich IEC 62443) überschneidet.

• 16. Sicherheitsbewusste Kontrollintegrität

Diese Säulen sind wichtig, weil die IEC 61508 nicht von Code beeindruckt ist, der "meistens" funktioniert. Sicherheitssoftware wird nach definiertem Verhalten unter definierter Belastung beurteilt.

Ein prüfungsreifes Artefakt ist kein Screenshot, kein Prompt-Protokoll oder eine vage Testnotiz. In diesem Kontext sollte es als zeitgestempelter Simulationsbericht definiert werden, der das beabsichtigte Steuerungssequenzverhalten mit den beobachteten Zustandsänderungen unter induzierten Fehlerbedingungen vergleicht.

Diese Definition hält den Nachweis an die Ausführung gebunden. Sie hält auch Produktversprechen in Grenzen. OLLA Lab kann die Erstellung dieses Nachweises unterstützen, indem es Simulation, Variablensichtbarkeit, Szenariostruktur und realistische Maschinenmodelle bereitstellt. Es ist selbst keine Konformitätsbehörde.

Ein nützliches prüfungsreifes Artefakt sollte enthalten:

1. Systembeschreibung Welche Ausrüstung oder welcher Prozess wird gesteuert, einschließlich wichtiger E/A, Sequenzabsicht und Betriebsmodi.
2. Operative Definition des korrekten Verhaltens Das erwartete Verhalten im Normalbetrieb und unter anormalen Bedingungen.
3. Kontaktplan-Logik und simulierter Anlagenzustand Die zu testende Logik und die entsprechende Maschinen- oder Prozessreaktion in der Simulation.
4. Der injizierte Fehlerfall Die exakt eingeführte anormale Bedingung, wie Drahtbruch, fehlender Nachweis, Analogwert außerhalb des Bereichs oder Wiederanlauf nach Stromausfall.
5. Die vorgenommene Überarbeitung Was sich in der Logik geändert hat, nachdem der Fehler beobachtet wurde.
6. Erkenntnisse Was der Fehler über Annahmen, Sequenzdesign, Verriegelungen oder Wartbarkeit offenbart hat.

Diese sechsteilige Struktur erzeugt technische Nachweise statt einer Screenshot-Galerie. Auditoren und leitende Prüfer benötigen einen Entscheidungspfad. Ebenso die Personen, die den Code später übernehmen.

Dokumentation sollte ein Nebenprodukt der Validierung sein, keine Aufräumaktion im Nachhinein. Wenn der Testprozess korrekt strukturiert ist, kann das Nachweispaket aus dem Workflow selbst zusammengestellt werden.

Ein praktischer Workflow sieht so aus:

1. Definieren der beabsichtigten Sequenz und Sicherheitsreaktion Festlegen, was die Anlage bei Lauf, Stopp, Start, Abschaltung und Fehlerbedingungen tun soll.
2. Erstellen oder Importieren der Kontaktplan-Logik Dies kann KI-generierte Entwurfslogik beinhalten, aber der Entwurf ist nur der Ausgangspunkt.
3. Ausführen der Logik im Simulationsmodus Das Programm ausführen und dabei Eingänge, Ausgänge, interne Tags, Analogwerte und Sequenzbits überwachen.
4. Gezieltes Injizieren von Fehlern Variablensteuerungen verwenden, um Drahtbrüche, fehlende Grenzwerte, veraltete Nachweise, Freigabeverluste, Analogwert-Exkursionen oder Neustartbedingungen zu simulieren.
5. Vergleichen von erwartetem und beobachtetem Verhalten Aufzeichnen, ob die simulierte Anlage in den korrekten sicheren Zustand geht und ob die interne Logik der Steuerungsphilosophie entspricht.
6. Überarbeiten der Logik und erneutes Testen Hinzufügen von deterministischen Vetos, Rücksetzbehandlung, Fehler-Speicherung oder Sequenzwächtern, wo nötig.
7. Exportieren des Testprotokolls Szenarioziel, Fehlerfall, beobachtete Zustandsänderungen und das endgültig akzeptierte Logikverhalten bewahren.

In OLLA Lab wird dieser Workflow durch den Kontaktplan-Editor, den Simulationsmodus, das Variablen-Panel, die Szenariostruktur und den Digital-Twin-Kontext unterstützt. Der entscheidende Punkt ist nicht, dass die Plattform die Konformität übernimmt. Der entscheidende Punkt ist, dass sie eine deterministische Beobachtungsumgebung bietet, in der Softwareverhalten gegen realistische Prozessbedingungen getestet werden kann.

Ein kompaktes Beispiel für deterministische Veto-Logik finden Sie unten:

[Sprache: Kontaktplan (Ladder Diagram)] // Beispiel: deterministisches Veto überschreibt generierte Lauf-Logik // Wenn AI_Run_Cmd wahr ist, aber Safety_Permissive abfällt, // muss Motor_Out bedingungslos zurückgesetzt werden.

|---[ AI_Run_Cmd ]----[ Safety_Permissive ]-----------( Motor_Out )---| | | |---[/Safety_Permissive ]--------------------------------(U Motor_Out)-|

Das wichtige Merkmal hier ist nicht stilistische Eleganz. Es ist, dass der Verlust der Freigabe eine explizite, testbare, bedingungslose Konsequenz hat.

OLLA Lab validiert Verhalten, nicht den Zertifizierungsstatus. Das ist die korrekte Grenze.

Die systematische Eignung gemäß IEC 61508 hängt von disziplinierten Entwicklungs- und Verifizierungspraktiken ab, die systematische Fehler reduzieren. Ein webbasierter Simulator kann die systematische Eignung nicht von sich aus verleihen, aber er kann die Umgebung bereitstellen, die erforderlich ist, um zu beobachten, ob sich die implementierte Logik in einer Weise verhält, die mit diesen disziplinierten Praktiken konsistent ist.

In der Praxis unterstützt OLLA Lab dies, indem es Ingenieuren ermöglicht:

• Kontaktplan-Logik mit Standard-Steuerungselementen zu erstellen, einschließlich Kontakten, Spulen, Timern, Zählern, Komparatoren, mathematischen Funktionen und PID-Anweisungen
• Logik in der Simulation ohne physische Hardware auszuführen
• Variablen, E/A, Analogwerte und PID-bezogene Parameter zu manipulieren
• Logik gegen realistische industrielle Szenarien statt gegen abstrakte Spielzeugprobleme zu testen
• Kontaktplan-Zustände mit 3D- oder WebXR-Anlagenverhalten zu vergleichen, sofern verfügbar
• anormale Bedingungen zu proben, die an einer realen Anlage unsicher oder teuer wären

Das ist wichtig, weil mathematische Korrektheit der Einheit nicht für die industrielle Steuerung ausreicht. Ein Kontaktplan-Zweig kann syntaktisch gültig sein und dennoch im Prozess versagen. Die Digital-Twin-Validierung ist gerade deshalb nützlich, weil sie die Interaktion zwischen Softwarezustand und simuliertem physikalischem Zustand offenlegt.

Operativ bedeutet Digital-Twin-Validierung hier, Kontaktplan-Logik gegen ein realistisches Maschinen- oder Prozessmodell laufen zu lassen und zu beobachten, ob erwartetes Anlagenverhalten, Sequenzfortschritt, Verriegelungen, Alarme und Übergänge in den sicheren Zustand sowohl unter normalen als auch unter fehlerhaften Bedingungen auftreten.

Realistische Szenarien legen die Steuerungsannahmen offen, die generische Übungen verbergen. Ein Motorstart-Tutorial kann Selbsthaltelogik lehren. Es lehrt normalerweise nicht den fehlgeschlagenen Nachweis, die Neustartsperre, die Lead-Lag-Arbitrierung, die Totzone von Analogalarmen oder was passiert, wenn ein Bedienerbefehl mit einer Auslösebedingung kollidiert.

Deshalb ist der Szenariokontext wichtig. Die dokumentierten Voreinstellungen von OLLA Lab für Wasser, Abwasser, HLK, Fertigung, Lagerhaltung, Lebensmittel und Getränke, Versorgungsunternehmen, Chemie und Pharma sind nicht nützlich, weil sie zahlreich sind, sondern weil sie die Logik in einen operativen Kontext zwingen.

Verschiedene Szenarien lehren unterschiedliche Sicherheits- und Inbetriebnahmemuster:

• Pumpensysteme lehren Lead-Lag-Rotation, Schutz bei niedrigem Füllstand, Erkennung fehlgeschlagener Starts, Überlaufrisiko.
• Förderbänder und Verpackungslinien lehren Stauerkennung, Sequenzfreigaben und koordiniertes Stoppverhalten.
• HLK- und Luftbehandlungssysteme lehren Verriegelungen, Ventilatornachweis, Klappenpositionslogik und Alarmbehandlung.
• Prozess-Skids lehren Analogschwellenwerte, PID-Interaktion, Auslöselogik und kontrollierte Abschaltung.
• Wasser- und Abwassersysteme lehren Füllstandsregelung, Lastwechsel, Alarmpriorisierung und Prozesskontinuität bei Anlagenausfällen.

Hier helfen auch geführte Bauanleitungen. Schnellstarts, E/A-Karten, Notizen zur Steuerungsphilosophie, Verriegelungen, Tag-Wörterbücher und Verifizierungsschritte geben dem Ingenieur eine strukturierte Basis für den Nachweis von Verhalten. Das ist nützlicher, als jemanden in einen leeren Editor zu werfen und es Realismus zu nennen.

Fehlertests sollten um beobachtbare Prozessrisiken herum entworfen werden, nicht um das, was die KI zufällig generiert hat. Die richtige Frage ist nicht: Läuft der Code?, sondern: Was passiert, wenn der Prozess lügt, stockt oder verschwindet?

Ein diszipliniertes Fehlertest-Set sollte mindestens enthalten:

• Verlust der Freigabe während des aktiven Laufs
• fehlende Rückmeldung oder fehlendes Nachweissignal
• Analogsignal hoch, niedrig, eingefroren oder außerhalb des Bereichs
• Stromausfall oder Neustart mit vorhandenen remanenten Bits
• asynchroner Bedienerbefehl während des Sequenzübergangs
• Kommunikationsverlust oder veraltete Daten, wo zutreffend
• Sensordiskrepanz, wo redundante oder bestätigende Signale existieren

Für jeden Fall sollte der Ingenieur definieren:

• die erwartete sichere Reaktion
• die maximal akzeptable Reaktionszeit
• die zu beobachtenden Tags und Ausgänge
• die Kriterien für Bestehen, Nichtbestehen und Überarbeitung

Das Variablen-Panel in OLLA Lab ist hier nützlich, da es die direkte Manipulation von Eingängen und die Sichtbarkeit des Zustands während der Ausführung ermöglicht. Das unterstützt Fehlerinjektion, Tag-Beobachtung und wiederholbare Nachtests. Auch hier ist der Wert begrenzt: Es ist eine kontrollierte Validierungsumgebung für risikoreiche Inbetriebnahmeaufgaben, kein Ersatz für formale Abnahmen vor Ort, Hardwareverifizierung oder Kompetenz an einem realen Prozess.

Ein Entscheidungspaket ist der zusammengestellte Nachweis, der erklärt, warum die endgültige Logik akzeptabel ist. In diesem Artikel sollte agentische Orchestrierung eng als der Akt des Ingenieurs verstanden werden, die generierte Logik zu überwachen, sie gegen definierte Szenarien zu testen, unsicheres Verhalten abzulehnen und die Begründung für akzeptierte Überarbeitungen zu bewahren.

Ein vertretbares Entscheidungspaket sollte enthalten:

• das Steuerungsziel
• die sicherheitsrelevanten Anforderungen oder Gefahrenminderungen
• die Revisionshistorie der Kontaktplan-Logik
• das verwendete Simulationsszenario
• die injizierten Fehlerfälle
• die beobachteten Ergebnisse
• das akzeptierte endgültige Verhalten
• die ungelösten Annahmen oder Grenzen
• die Basis für die Freigabe zur nächsten Überprüfungsstufe

OLLA Lab trägt zu diesem Paket bei, indem es durch geführte Szenarien, Variablensichtbarkeit, Simulationsausführung und Digital-Twin-Kontext Struktur in die Bau-und-Verifizier-Schleife bringt. Es hilft Ingenieuren, Nachweise zu erstellen, die überprüft werden können. Das ist die nützliche Schwelle.

KI kann die Entwurfserstellung beschleunigen, aber sie reduziert nicht die Beweislast. Bei sicherheitsrelevanter Software ist Geschwindigkeit ohne Nachweis nur ein schnellerer Weg zu unverifizierter Logik.

Die praktischen Regeln sind einfach:

• behandeln Sie generierte Kontaktplan-Logik als Entwurf, niemals als akzeptierte Wahrheit
• definieren Sie korrektes Verhalten vor dem Testen
• validieren Sie gegen Prozessverhalten, nicht nur gegen das Aussehen der Kontaktplan-Zweige
• injizieren Sie Fehler absichtlich
• bewahren Sie zeitgestempelte Nachweise der erwarteten gegenüber der beobachteten Reaktion auf
• überarbeiten Sie auf Determinismus, Lesbarkeit und Rückverfolgbarkeit
• halten Sie den menschlichen Ingenieur für die Abnahme verantwortlich

Das ist die echte Generierungs-Validierungs-Schleife. Sie ist weniger glamourös als Behauptungen, dass KI SPS-Code schreibt, und nützlicher in der Sicherheitsarbeit.

- Lesen Sie "The Deterministic Veto: Programming Safety PLCs" für eine tiefere Behandlung von harten Verriegelungen und bedingungsloser Logik für den sicheren Zustand.

• Kehren Sie zum "Future of Automation Hub" zurück, um mehr über resiliente Engineering-Workflows und simulationsgeführte Validierung zu erfahren.
• Überprüfen Sie die "EU AI Act High-Risk Compliance", falls Ihr Automatisierungsworkflow auch neue Anforderungen an die KI-Governance erfüllen muss.
• Bereit, Fehlerverhalten direkt zu testen? Öffnen Sie das "Safety Interlock Scenario" in OLLA Lab und validieren Sie Logik gegen ein simuliertes Maschinenmodell.

- 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 Ampergon Vallis Lab spezialisiert sich auf die Schnittstelle zwischen industrieller Automatisierung, funktionaler Sicherheit und KI-gestützten Entwicklungswerkzeugen.

Dieser Artikel wurde anhand der Anforderungen der IEC 61508-3 für Software-Lebenszyklusaktivitäten und der Best Practices für die Validierung von SPS-Logik in simulierten Umgebungen überprüft.