Wie GeniAI im Vergleich zu Ingenieuren bei der Standardisierung sicherer SPS-Logik abschneidet

Beim Vergleich von GeniAI mit menschlichen Ingenieuren für die SPS-Programmierung zeigt sich, dass KI wiederholbare Sicherheitszustandsmuster in Logikentwürfen konsistenter durchsetzen kann, während Menschen für die Validierung des physikalischen Verhaltens, anomaler Zustände und Inbetriebnahmerisiken unerlässlich bleiben. OLLA Lab bietet eine begrenzte Simulationsumgebung, um KI-generierte Kontaktplan-Logik (Ladder Logic) vor der Implementierung gegen realistische Anlagenreaktionen zu testen.

KI löst SPS-Sicherheitsprobleme nicht dadurch, dass sie „intelligenter“ als Ingenieure ist. Sie hilft, indem sie bei repetitiven Strukturen weniger inkonsistent ist. In der funktionalen Sicherheit ist dieser Unterschied wichtiger, als es das Marketing oft vermuten lässt.

Die IEC 61508 befasst sich mit der Vermeidung systematischer Fehler in Software und Logikdesign, nicht nur mit dem Nachweis, dass Hardware seltener ausfällt. In der Praxis entstehen viele gefährliche Steuerungsfehler vorgelagert bei der Spezifikation, Sequenzierung, Verriegelung, dem Rücksetzverhalten und der Fehlerbehandlung. Der Fehler ist oft architektonisch, bevor er elektrisch wird.

Interne Benchmarks von Ampergon Vallis ergaben, dass bei 500 Simulationsläufen in OLLA Lab die von GeniAI generierten Not-Halt-Kettenentwürfe eine Fehlerquote von 0 % bei den getesteten Zustands-Rücksetzbedingungen aufwiesen, während von Menschen geschriebene Zwischenentwürfe in 14 % der Läufe das Selbsthalteverhalten bei simulierten Stromausfällen oder Rücksetz-Flankenfällen nicht korrekt unterbrachen. Die Methodik umfasste 500 Simulationszyklen über Benutzerprojektvarianten hinweg, die sich auf Not-Halt- und Rücksetzbehandlung konzentrierten, im Vergleich zu manuell erstellten Kontaktplan-Entwürfen, beobachtet während eines internen Laborprüfungszeitraums im ersten Quartal 2026. Dies stützt eine eng gefasste Aussage über die Wiederholbarkeit standardisierter Fehlerbehandlungsmuster. Es beweist nicht, dass KI-generierte Logik sofort einsatzbereit, anlagensicher oder über alle Steuerungsaufgaben hinweg überlegen ist.

Menschliche Ingenieure haben oft Schwierigkeiten mit der systematischen Eignung, weil sie primär für den Maschinenbetrieb optimieren und nicht für fehlertolerantes Verhalten in Grenzbereichen. „Es läuft“ ist nicht dasselbe wie „es schaltet sicher ab“.

Gemäß IEC 61508 betrifft die systematische Eignung die Sorgfalt, mit der designbedingte Fehler in sicherheitsbezogenen Systemen verhindert werden. Die Norm fragt nicht, ob der Code clever ist. Sie fragt, ob der Prozess, die Struktur und die Verifizierungsdisziplin vermeidbare Logikdefekte reduzieren, insbesondere solche, die durch Spezifikationsfehler, Auslassungen oder schwache Behandlung anomaler Zustände wiederholt auftreten.

Ein praktisches Fehlermuster ist, dass von Menschen geschriebene Kontaktplan-Logik oft implizites Wissen (Tribal Knowledge) statt expliziter Designabsicht enthält. Das zeigt sich meist durch:

• unbeschriftete Annahmen über den Startzustand,
• Freigabebedingungen, die tief in der Produktionslogik eingebettet sind,
• Rücksetzverhalten, das von der Gewohnheit des Bedieners abhängt,
• Timer-Ketten, die explizite Sequenzzustände ersetzen,
• Fehlerreaktionen, die im Kopf des Autors klarer existieren als im Code.

Dies ist ein Grund, warum geerbter SPS-Code spröde wird. Die Maschine läuft zwar noch, aber die Logik ist nicht mehr auditierbar.

Was bedeutet „Standardisierung sicherer Logik“ operativ?

Sichere Logik zu standardisieren bedeutet, sicherheitsrelevante Verhaltensweisen in beobachtbaren, wiederholbaren Designmustern auszudrücken, anstatt in einem persönlichen Stil. In Bezug auf Kontaktpläne umfasst dies normalerweise:

• explizite Deklaration des ausfallsicheren Zustands für Ausgänge und Sequenzen,
• Verwendung von nicht-remanentem Verhalten für Freigabepfade, sofern Remanenz nicht explizit gerechtfertigt ist,
• Trennung von Basissteuerungslogik und Sicherheitsverriegelungen sowie Abschaltungen,
• Erfordernis expliziter Rücksetzbedingungen nach Fehlern,
• Anwendung von Entprell- oder Validierungstimern bei verrauschten physikalischen Eingängen,
• Kopplung von befohlenen Zuständen mit Rückmeldungsüberwachung, wenn der Prozess einen Bewegungsnachweis, Durchflussnachweis oder Geräteantwortnachweis erfordert.

Das ist keine glamouröse Arbeit, aber viele vermeidbare Fehler liegen genau dort.

Warum schwächt „Zwiebellogik“ die Sicherheitsdisziplin?

Tief verschachtelte bedingte Logik schwächt die Sicherheitsdisziplin, da sie Zustandsbeziehungen verbirgt und es schwieriger macht, anomales Verhalten nachzuvollziehen. Der Code mag zwar unter den Syntaxregeln der IEC 61131-3 fehlerfrei kompilieren, aber Syntaxkonformität ist keine Einsatzbereitschaft.

Ein häufiges menschliches Muster ist die allmähliche Anhäufung von Netzwerkausnahmen: noch eine Umgehung, noch eine Wartungsverriegelung, noch ein Timer zur Unterdrückung von Störmeldungen. Schließlich wird die Logik zu einem Stapel lokaler Korrekturen ohne stabiles globales Modell. Die Maschine startet immer noch – bis sie aus dem falschen Grund startet.

GeniAI ist am stärksten, wenn die Aufgabe Wiederholung, explizite Struktur und standardkonforme Vorlagen belohnt. KI wird nicht müde, dasselbe Verriegelungsmuster wiederholt zu schreiben.

Innerhalb begrenzter SPS-Entwurfsaufgaben kann dies sauberere Logik für den ersten Entwurf erzeugen bei:

• Freigabeketten,
• Rücksetzstrukturen,
• Zustandsautomaten-Gerüsten,
• Alarmkopplungen,
• Rückmeldungsprüfungen,
• expliziten Fehlerzweigen.

Diese Stärke sollte eng verstanden werden. Es geht um die Konsistenz der Musteranwendung, nicht um autonomes ingenieurtechnisches Urteilsvermögen.

Wie verhält sich dies zur IEC 61131-3?

Die IEC 61131-3 definiert die formalen Programmiersprachen und Strukturen für die industrielle Steuerung, einschließlich Kontaktplan (LD) und Strukturierter Text (ST). Der Nutzen der Entwürfe von GeniAI hängt teilweise davon ab, innerhalb dieser formalen Strukturen zu bleiben, anstatt Pseudocode zu improvisieren, der plausibel aussieht, aber in einer SPS-Umgebung nicht ausführbar ist.

Das ist wichtig, weil industrielle Logik nicht nur nach Lesbarkeit beurteilt wird. Sie muss auf deterministische Ausführung, Tag-Verhalten, Zykluszeit-Realitäten und eine wartbare Programmorganisation abgebildet werden.

KI- vs. menschliche Logikmuster

Der Vergleich ist auf Musterebene am deutlichsten.

| Steuerungsmuster | GeniAI-Tendenz | Menschliche Tendenz | Ingenieurtechnische Konsequenz | |---|---|---|---| | Freigaben | Verwendet explizite Bedingungsketten und sichtbare Gating-Logik | Komprimiert Logik oft in Latch/Unlatch-Abkürzungen | Reduzierte Mehrdeutigkeit gegenüber verstecktem remanentem Verhalten | | Sequenzsteuerung | Bevorzugt explizite Zustandsvariablen oder strukturierte Übergänge | Verlässt sich oft auf Timer-Kaskaden und Ad-hoc-Verzweigungen | Bessere Rückverfolgbarkeit gegenüber spröder Zeitabhängigkeit | | Fehlerbehandlung | Koppelt Befehle eher mit Alarm- oder Fehlerzweigen im Entwurf | Lässt unter Termindruck häufig Rückmeldungen weg | Bessere Erstabdeckung anomaler Zustände | | Rücksetzverhalten | Neigt dazu, Rücksetzbedingungen explizit zu machen | Setzt oft Bedienerwissen oder Startkonventionen voraus | Sicherere Wiederanlauflogik und klarere Inbetriebnahmetests | | Vorlagenkonsistenz | Hoch | Variabel je nach Ingenieur, Ermüdung und Projektdruck | Geringere Musterdrift über ähnliche Funktionen hinweg |

Der entscheidende Unterschied ist einfach: KI ist gut in deterministischer Wiederholung; Menschen sind gut in kontextueller Ausnahmebehandlung. Sichere Projekte benötigen beides.

### Beispiel: Standardisierte Not-Halt- und Rücksetzstruktur

Unten ist ein vereinfachtes Beispiel im Kontaktplan-Stil für eine standardisierte Not-Halt-Kette und ein kontrolliertes Neustartmuster.

Sprache: Kontaktplan (Ladder Diagram) - IEC 61131-3

|---[/]------[/]------[ ]-------------------------( )---| NOT_HALT SCHUTZ_1 RÜCKSETZ_TASTE SYS_OK

|---[ ]------[ ]------[/]-------------------------( )---| SYS_OK START_TASTE MOTOR_FEHLER MOTOR_LAUF

|---[ ]-------------------------------------------( )---| MOTOR_LAUF LAUF_BEFEHL

Dieses Muster ist nicht allein deshalb sicher, weil es ordentlich aussieht. Es wird sicherer, wenn der Fehlerzustand explizit ist, der Neustart bewusst erfolgt und die Fehlerbehebung unter simulierten anomalen Bedingungen testbar ist.

KI-generiertem SPS-Code fehlt die physikalische Intuition. Er kann strukturell saubere Logik erzeugen, die ignoriert, wie sich Maschinen tatsächlich fehlerhaft verhalten.

Dies ist die zentrale Einschränkung. Ein Entwurf kann syntaktisch korrekt und normgerecht sein und dennoch für die Anlage falsch. Das Problem ist meist die gewöhnliche Feldrealität:

• Ventile klemmen,
• Näherungsschalter prellen,
• Antriebe laufen aus,
• Pumpen verlieren die Ansaugung,
• Analogsignale driften,
• Bediener drücken Tasten nicht immer in der von der Steuerungsphilosophie vorgesehenen Reihenfolge.

Ein Sprachmodell erfährt keine mechanische Trägheit oder Relaisprellen. Das ist eine praktische Einschränkung, keine rhetorische.

Was ist der „Sieht-korrekt-aus“-Trugschluss?

Der „Sieht-korrekt-aus“-Trugschluss ist die Annahme, dass eine gut strukturierte Kontaktplan-Logik operativ korrekt ist, weil ihr Fluss auf dem Bildschirm diszipliniert erscheint.

Beispiele hierfür sind:

• eine Fördersequenz, die für die Räumzeit nachgelagerter Prozesse zu schnell neu startet,
• eine Pumpen-Wechselroutine, die die Verzögerung von Füllstandssensoren ignoriert,
• ein PID-Regler mit mathematisch plausiblen Verstärkungsfaktoren, aber ohne Berücksichtigung von Ventilhaftreibung oder Totband,
• eine Motoren-Freigabekette, die davon ausgeht, dass Rückmeldungsübergänge sofortig und sauber sind.

KI kann diese Muster überzeugend entwerfen. Sie kann nicht unabhängig validieren, ob der physikalische Prozess sie toleriert.

Wo menschliche Ingenieure die KI immer noch übertreffen

Menschliche Ingenieure bleiben überall dort notwendig, wo Steuerungslogik von Prozessurteil, mechanischem Kontext oder standortspezifischem anomalem Verhalten abhängt. Dazu gehören:

• Interpretation unvollständiger oder widersprüchlicher Spezifikationen,
• Erkennen von Wartungsrealitäten und Umgehungslösungen durch Bediener,
• Verständnis der Fehlermodi spezifischer Geräte,
• Abwägung von Störmeldungen gegenüber echten Gefahrenreaktionen,
• Entscheidung, ob eine Sequenz lediglich funktional oder tatsächlich inbetriebnahmefähig ist.

Der praktische Kontrast besteht zwischen Entwurfserstellung und deterministischem Veto. Der Mensch besitzt weiterhin das Veto.

KI-generierte Kontaktplan-Logik sollte als strukturierter Entwurf betrachtet werden, der vor jeder Implementierungsentscheidung gegen simuliertes Maschinenverhalten validiert werden muss. Hier wird OLLA Lab operativ nützlich.

OLLA Lab ist am besten als risikobegrenzte Validierungs- und Übungsumgebung für Steuerungslogik zu verstehen. Es ist kein Anspruch auf Standortkompetenz, Zertifizierung, SIL-Qualifizierung oder automatische Implementierbarkeit. Es gibt Ingenieuren einen Ort, um Ursache und Wirkung zu testen, E/A zu inspizieren, Fehler einzuspeisen und den Kontaktplan-Zustand gegen simuliertes Anlagenverhalten zu vergleichen, bevor die Live-Inbetriebnahme die Konsequenzen trägt.

Was bedeutet „Simulationsbereit“ operativ?

Simulationsbereit bedeutet, dass ein Ingenieur Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor sie einen Live-Prozess erreicht.

Operativ umfasst dies die Fähigkeit:

• Kontaktplan-Logik in einem strukturierten Editor zu erstellen oder zu überprüfen,
• Tags an simuliertes Anlagenverhalten zu binden,
• Live-Eingänge, -Ausgänge und interne Variablen zu überwachen,
• anomale Bedingungen gezielt zu erzwingen,
• zu verifizieren, dass der Prozess korrekt in sichere Zustände eintritt und diese verlässt,
• Logik nach beobachteten Fehlern zu überarbeiten,
• zu dokumentieren, warum das überarbeitete Verhalten korrekter ist als das ursprüngliche.

Die Kontaktplan-Syntax zu kennen, reicht nicht aus. Syntax ist die Grundvoraussetzung; das Urteilsvermögen bei der Inbetriebnahme ist der teure Teil.

Was ist der Sim-to-Real-Workflow in OLLA Lab?

Der Sim-to-Real-Workflow in OLLA Lab ist eine begrenzte Validierungssequenz zum Testen von Entwurfslogik gegen realistische Szenarien.

Dieser Workflow ist wertvoll, weil er den Teil lehrt, den viele Junior-Ingenieure selten sicher üben können: fehlerhaftes Verhalten. Normalbetrieb ist die einfache Demo. Anomaler Betrieb ist der Punkt, an dem Ingenieurwesen am folgenreichsten wird.

1. Erstellen oder Importieren der Kontaktplan-Logik im webbasierten Ladder Logic Editor unter Verwendung von Konstrukten im Stil der IEC 61131-3 wie Kontakte, Spulen, Timer, Zähler, Komparatoren, mathematische Funktionen und PID-Anweisungen.
2. Auswahl eines Szenarios, das den beabsichtigten Maschinen- oder Prozesskontext widerspiegelt, wie z. B. Motorstarter, Pumpstation, Förderband, HVAC-Einheit oder Prozess-Skid.
3. Binden von Tags und Inspizieren von Variablen über das Variablen-Panel, einschließlich digitaler E/A, Analogwerte, Tag-Zustände und PID-bezogener Variablen, wo zutreffend.
4. Ausführen des Simulationsmodus und Beobachten des Basisverhaltens unter normalen Start-, Lauf-, Stopp- und Rücksetzbedingungen.
5. Einspeisen von Fehlerfällen wie Sensorausfall, Rückmeldungsfehler, Äquivalente von Aderbrüchen, Verriegelungsauslösungen oder anomale Analogwerte.
6. Vergleichen des Kontaktplan-Zustands mit dem Anlagenzustand in der 3D- oder WebXR-Simulation, um festzustellen, ob die Logikreaktion im Code lediglich zulässig oder für die Maschine tatsächlich korrekt ist.
7. Überarbeiten und erneutes Testen, bis das Fehlerverhalten, der Wiederherstellungspfad und die Bedienerinteraktionen explizit und stabil sind.

Was sollten Ingenieure zuerst testen?

Ingenieure, die KI-generierte Logik in OLLA Lab validieren, sollten das Verhalten bei anomalen Zuständen testen, bevor sie den Nominalbetrieb verfeinern. Empfohlene Erstprüfungen umfassen:

• Hat jeder befohlene Ausgang eine definierte ausfallsichere Reaktion?
• Entfernt der Verlust einer Freigabe den Ausgang sofort und vorhersehbar?
• Erfordert das Rücksetzen eine explizite Bedieneraktion, wo dies erforderlich ist?
• Werden Rückmeldungen überwacht, wo der Prozess von ihnen abhängt?
• Filtern Timer Rauschen, ohne echte Auslösungen zu maskieren?
• Erholt sich die Sequenz sauber nach Stromausfall oder Fehlerbehebungsbedingungen?
• Verhalten sich Analogalarme und PID-bezogene Aktionen an den Schwellenwerten sinnvoll?

Ein Kontaktplan-Entwurf, der diese Prüfungen übersteht, ist immer noch nicht automatisch feldbereit. Er ist lediglich besser auf eine ernsthafte Überprüfung vorbereitet.

Ingenieure sollten einen kompakten Satz an ingenieurtechnischen Nachweisen dokumentieren, keine Screenshot-Galerie. Ein Screenshot beweist nur, dass die Software geöffnet war. Er beweist nicht, dass ein Denkprozess stattgefunden hat.

Verwenden Sie diese Struktur:

Geben Sie an, was korrektes Verhalten in beobachtbaren Begriffen bedeutet: Startbedingungen, Auslösebedingungen, sicherer Zustand, Rücksetzregeln und erwartete Rückmeldungen.

Identifizieren Sie die eingeführte anomale Bedingung: fehlgeschlagene Rückmeldung, verrauschter Sensor, klemmende Ventilanzeige, Analogwert-Überbereich, Not-Halt oder Stromausfall- und Rücksetzfall.

1. Systembeschreibung Definieren Sie die Maschine oder den Prozess, das Ziel, die wichtigsten E/A und kritische Verriegelungen.
2. Operative Definition des korrekten Verhaltens
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die relevanten Netzwerke und den entsprechenden simulierten Maschinenzustand oder die Prozessreaktion.
4. Der eingespeiste Fehlerfall
5. Die vorgenommene Überarbeitung Erklären Sie, was sich in der Logik geändert hat und warum die Änderung die Determiniertheit, Sicherheit oder Wiederherstellbarkeit verbessert.
6. Gelernte Lektionen Fassen Sie die ingenieurtechnische Erkenntnis zusammen, nicht nur das Endergebnis.

Diese Struktur erzeugt Nachweise für Urteilsvermögen und Überprüfbarkeit.

KI ersetzt den menschlichen Ingenieur beim sicheren SPS-Design nicht. Sie verlagert die menschliche Rolle von der manuellen Erstellung jedes repetitiven Musters hin zur Spezifizierung, Überprüfung, Validierung und Ablehnung von Logik mit größerer Disziplin.

Wenn die Aufgabe die Standardisierung von Vorlagen ist, kann KI viele Menschen in der Konsistenz übertreffen. Wenn die Aufgabe darin besteht, zu entscheiden, ob eine Pumpstation bei Schacht-Wellen, Sensorverzögerung und Bediener-Override sicher reagiert, bleibt der Mensch verantwortlich.

Eine praktische Arbeitsteilung sieht so aus:

• KI entwirft wiederholbare Strukturen, Verriegelungen, Zustandsgerüste und Alarmkopplungen.
• Menschen definieren Prozessabsicht, Erwartungen an anomale Zustände und Akzeptanzkriterien.
• Simulation validiert, ob die Logik korrekt gegen realistische Anlagenbedingungen reagiert.
• Implementierungsentscheidungen bleiben eine menschliche ingenieurtechnische Verantwortung.

Dies ist kein philosophischer Kompromiss. Es ist ein praktischer Weg, mit Risiken umzugehen, wenn Code physikalische Anlagen steuert.

GeniAI schneidet in einem engen, aber wichtigen Bereich günstig im Vergleich zu menschlichen Ingenieuren ab: Sie kann standardisierte Sicherheitszustandsmuster konsistenter in SPS-Logikentwürfe einfügen. Das ist wichtig, weil systematische Fehler oft in der Logikstruktur, durch Auslassungen und schwache Behandlung anomaler Zustände entstehen, nicht nur in der Hardware allein.

Aber Konsistenz ist keine Kompetenz. KI kann Syntax und Muster standardisieren; sie kann die Prozessrealität nicht unabhängig validieren. Sichere SPS-Arbeit erfordert weiterhin menschliche Überprüfung, physikalisches Denken und fehlerbasierte Validierung.

Deshalb ist OLLA Lab in diesem Workflow wichtig. Es gibt Ingenieuren einen begrenzten Ort, um KI-generierte Kontaktplan-Logik gegen simuliertes Anlagenverhalten zu testen, E/A zu inspizieren, Fehler einzuspeisen und Logik zu überarbeiten, bevor eine Live-Anlage zum Teststand wird. Live-Anlagen sind schlechte Orte, um zu entdecken, dass ein Rücksetzpfad nur impliziert statt konstruiert wurde.

- IEC 61508 Functional Safety overview - IEC 61131-3 standard overview (PLCopen) - NIST AI Risk Management Framework (AI RMF 1.0) - ISO/IEC 23894:2023 AI risk management standard page - IEEE Xplore: industrial automation and AI safety publications