Programmierung eines deterministischen Vetos in einer Sicherheits-SPS zur Übersteuerung von KI-Halluzinationen

Um KI-Halluzinationen in der industriellen Automatisierung zu übersteuern, müssen Ingenieure die KI hinter ein deterministisches SPS-Veto schalten. Die SPS sollte von der KI angeforderte Befehle vor jeder Aktuierung gegen feste Grenzwerte, Zustandsfreigaben und festverdrahtete Sicherheitsfunktionen prüfen. Diese mehrschichtige Verteidigung trennt probabilistische Optimierung von deterministischer Ausführung.

KI wird nicht dadurch sicher, dass sie überzeugt klingt. In der industriellen Steuerungstechnik ist Vertrauen keine Regelgröße.

Der technische Konflikt ist eindeutig: LLMs und agentenbasierte KI-Systeme sind probabilistisch und nicht-deterministisch, während SPSen Logik in wiederholbaren Zykluszeiten mit begrenztem Verhalten ausführen. Dieser Unterschied ist nicht philosophischer Natur. Er ist architektonisch und in sicherheitsrelevanten Kontexten entscheidend.

In einer kürzlich durchgeführten internen Testreihe mit 500 simulierten KI-generierten Sollwertanomalien, die durch die digitalen Zwilling-Validierungsworkflows von OLLA Lab liefen, blockierte eine SPS-seitige Änderungsratenbegrenzung (Rate-of-Change Clamp) in Verbindung mit expliziten Zustandsfreigaben 100 % der katastrophalen, unzulässigen Befehle, bevor diese die virtuellen Ventil- und Motormodelle ansteuern konnten. Methodik: n=500 injizierte Anomaliefälle bei Aufgaben zu Geschwindigkeit, Druck und Ventilposition; Basis-Vergleich: direkte Durchleitung des KI-angeforderten Befehls an das simulierte Aktuator-Tag; Zeitfenster: interne Laborläufe von Ampergon Vallis, Q1 2026. Dies unterstreicht den Wert deterministischer Verifizierung in der Simulation. Es stellt keine IEC 61508-Zertifizierung, keinen SIL-Nachweis und keinen Anspruch auf Gültigkeit für alle Anlagenarchitekturen dar.

Die praktische Antwort besteht nicht darin, KI zu verbieten. Sie besteht darin, der KI die direkte Ausführungsautorität zu entziehen und von der SPS ein dauerhaftes, deterministisches Veto zu verlangen.

KI-Halluzinationen erfordern ein deterministisches Veto, da KI-Ausgaben nicht garantiert begrenzt, wiederholbar oder zyklussynchron sind – im Gegensatz zur SPS-Ausführung.

In einem Steuerungssystem ist ein unsicherer Befehl unsicher, selbst wenn er von einem statistisch beeindruckenden Modell generiert wurde. Ein Ventil interessiert sich nicht dafür, dass die Token-Wahrscheinlichkeit überzeugend aussah.

IEC 61508 und ISO 13849 basieren auf vorhersehbarem Verhalten, definierter Fehlerbehandlung und bekannten sicheren Zuständen. Sicherheitsbezogene Steuerungsfunktionen müssen auf eine Weise ausfallen, die analysiert, begrenzt und validiert werden kann. Aktuelle LLM-basierte Systeme erfüllen diesen Standard nicht, da ihre Fehlermodi nicht in der Weise erschöpfend charakterisierbar sind, wie es deterministische Sicherheitslogik erfordert. Das ist das eigentliche Problem: Nicht, dass KI neu ist, sondern dass KI nicht systematisch genug begrenzt ist, um den finalen Aktuierungspfad zu kontrollieren.

Der Zyklus vs. die Inferenz-Engine

Eine SPS führt Logik zyklisch aus. Sie liest Eingänge ein, löst die Logik, aktualisiert Ausgänge und wiederholt dies in einem bekannten Intervall, oft im niedrigen Millisekundenbereich, abhängig von Plattform, Aufgabenstruktur und Last.

Eine KI-Inferenz-Engine verhält sich nicht so. Ihre Antwortzeit variiert je nach Modellgröße, Rechenkapazität, Netzwerkbedingungen, Orchestrierungs-Overhead und Prompt-Komplexität. Selbst wenn die durchschnittliche Latenz akzeptabel erscheint, bleiben das Worst-Case-Timing und das Ausgabeverhalten das Problem.

Dies schafft zwei Arten von Risiken:

- Timing-Risiko: Die KI-Antwort kann verspätet, in falscher Reihenfolge oder während eines ungültigen Maschinenzustands eintreffen. - Inhaltsrisiko: Die KI-Antwort kann eine unmögliche, unsichere oder kontextlose Aktion anfordern.

Eine SPS kann verzögerte oder abgelehnte Anfragen tolerieren. Ein Pumpenstrang kann keine Fantasiegebilde tolerieren.

Was fordern die Normen tatsächlich?

Die Normen fordern vorhersehbares Sicherheitsverhalten, keine modische Software.

Auf hoher Ebene:

• IEC 61508 befasst sich mit der funktionalen Sicherheit von elektrischen, elektronischen und programmierbaren elektronischen sicherheitsbezogenen Systemen.
• ISO 13849 befasst sich mit sicherheitsbezogenen Teilen von Steuerungssystemen, insbesondere im Maschinenkontext.
• Beide Rahmenwerke hängen von definierten Architekturen, validiertem Verhalten und bekannten Reaktionen auf Fehlerzustände ab.

Das bedeutet nicht, dass jede nicht-deterministische Softwarekomponente überall im industriellen Stack verboten ist. Es bedeutet, dass nicht-deterministische Komponenten nicht als letzte Sicherheitsinstanz behandelt werden sollten. Die Unterscheidung ist wichtig. Wahrnehmung und Optimierung können probabilistisch sein; das Veto und der Abschaltpfad dürfen es nicht sein.

Ein deterministisches Veto ist eine fest codierte, zyklusgebundene Logikstruktur, die einen angeforderten Befehl bewertet und diesen blockiert, klemmt oder übersteuert, wenn der Befehl physikalische Grenzwerte, Prozessbeschränkungen oder Maschinenzustandsfreigaben verletzt.

Dies ist eine operative Definition, kein Slogan. Ein deterministisches Veto muss in der Logik beobachtbar und gegen Fehlerfälle testbar sein.

In der Praxis umfasst ein deterministisches Veto oft:

- Grenzwertprüfung: Ablehnung oder Begrenzung von Werten oberhalb oder unterhalb zulässiger Grenzen. - Änderungsratenbegrenzung: Verhinderung abrupter Änderungen über sichere Rampenraten hinaus. - Zustandsfreigaben: Zulassen von Befehlen nur in gültigen Betriebszuständen. - Rückmeldeprüfungen: Erfordernis einer Bestätigung von Feldgeräten vor dem Fortschreiten der Sequenz. - Alarm- und Abschaltbehandlung: Erzwingen einer sicheren Reaktion bei anormalen Bedingungen. - Modus-Isolierung: Verhindern von fern- oder KI-gesteuerten Aktionen in lokalen, Wartungs- oder Fehlermodi.

Wenn die KI 150 % Antriebsgeschwindigkeit anfordert und die SPS diese auf das konfigurierte Maximum begrenzt und einen Alarm auslöst, hat das Veto funktioniert. Wenn die KI direkt in das Ausgangsabbild schreiben kann, ist die Architektur falsch.

Operative Definitionen, auf die es ankommt

Diese Begriffe werden oft ungenau verwendet. Das sollten sie nicht.

- Deterministisches Veto: SPS-Logik, die eine externe oder KI-generierte Anfrage in jedem Zyklus bewertet und unsichere Ausführungen durch explizite Grenzwerte, Freigaben und Fehlerregeln blockiert. - Mehrschichtige Verteidigung (Layered Defense): Architektonische Trennung zwischen KI/IT-Funktionen, die vorschlagen oder optimieren, und SPS/OT-Funktionen, die Sicherheitsgrenzen verifizieren, ausführen und durchsetzen. - Simulationsbereit (Simulation-Ready): Die Fähigkeit, I/O-Kausalität nachzuverfolgen, anormales Verhalten zu beobachten, Fehlerfälle zu injizieren, die Steuerungsreaktion zu diagnostizieren und die Logik in einer virtuellen Umgebung zu überarbeiten, bevor physische Hardware berührt wird.

„Simulationsbereit“ ist keine Abkürzung für „kann Ladder-Syntax schreiben“. Es bedeutet, dass der Ingenieur das Verhalten unter Stress beweisen kann. Syntax ist billig; Einsatzfähigkeit ist es nicht.

Die korrekte mehrschichtige Verteidigungsarchitektur verleiht der KI Einfluss, ohne ihr ungeprüfte Autorität zu geben.

Die Trennung sollte explizit sein:

### Schicht 1: KI-Agent für Wahrnehmung oder Optimierung

Diese Schicht kann:

• Bedarf schätzen,
• Sollwerte vorschlagen,
• Routing empfehlen,
• Betriebszustände klassifizieren,
• Entwürfe für Logik oder Bedienerführung generieren.

Diese Schicht sollte nur in Zwischenspeicher-Tags, Nachrichtenstrukturen oder übergeordnete Anfragevariablen schreiben. Sie sollte nicht direkt in physische Ausgänge oder Sicherheitsspeicher schreiben.

### Schicht 2: Deterministisches Veto in der SPS

Diese Schicht bewertet die KI-Anfrage gegen feste technische Regeln wie:

• max./min. zulässige Werte,
• gültige Maschinenzustände,
• Verriegelungen,
• Freigabebedingungen,
• Anforderungen an Sequenzschritte,
• Alarm- und Abschaltbedingungen,
• Änderungsratenbegrenzungen.

Hier wird der Befehl entweder akzeptiert, modifiziert oder abgelehnt.

### Schicht 3: Festverdrahteter oder zertifizierter Sicherheitsausführungspfad

Diese Schicht umfasst, sofern zutreffend:

• Not-Halt-Ketten,
• Sicherheitsrelais,
• Sicherheits-SPS-Aufgaben,
• Schütze,
• STO-Schaltkreise (Safe Torque Off),
• Schutztürverriegelungen,
• unabhängige Abschaltfunktionen.

Diese Schicht muss außerhalb der KI-Speicherabbildung und außerhalb jeglicher weichen, übergeordneten Optimierung bleiben. Festverdrahtete Sicherheit existiert, weil Software gelegentlich eigene Meinungen entwickelt.

Sie programmieren das Veto, indem Sie jeden KI-angeforderten Befehl durch eine explizite Verifizierungslogik zwingen, bevor er die finale Regelgröße beeinflussen kann.

Das wichtigste Designprinzip ist einfach: KI-Anfragen sind Vorschläge, keine Ausgaben.

Implementierung der Sollwertbegrenzung

Eine Grenzwertbegrenzung verhindert, dass unmögliche oder unsichere Werte den Aktuatorbefehl erreichen.

Verwenden Sie eine Struktur wie diese:

Beispiel für Strukturierter Text / Kontaktplan-Übersetzung:

IF AI_Requested_Speed > Max_Allowable_Speed THEN Actual_Drive_Speed := Max_Allowable_Speed; Set Alarm_AI_Hallucination_Over_Speed; ELSIF AI_Requested_Speed < Min_Allowable_Speed THEN Actual_Drive_Speed := Min_Allowable_Speed; Set Alarm_AI_Hallucination_Under_Speed; ELSE Actual_Drive_Speed := AI_Requested_Speed; END_IF;

Das ist das Mindestmuster, nicht die fertige Architektur.

Eine produktionsorientierte Implementierung fügt normalerweise hinzu:

- Modusprüfung: KI-Anfragen nur im Automatikmodus akzeptieren. - Zustandsfreigabe: Anfragen nur akzeptieren, wenn sich die Maschine in einem gültigen Sequenzzustand befindet. - ROC-Begrenzung: Änderung pro Zyklus oder pro Sekunde begrenzen. - Qualitätsbit: Veraltete, ungültige oder nicht vertrauenswürdige Upstream-Daten ablehnen. - Timeout-Behandlung: Auf Fallback-Wert zurückgreifen, wenn der Anfragestrom abbricht. - Alarm-Speicherung und Bediener-Sichtbarkeit: Ablehnung sichtbar und überprüfbar machen.

Ein vollständigerer Steuerungspfad sieht oft so aus:

1. Empfang von `AI_Requested_Speed`
2. Validierung der Quellenqualität und Aktualität
3. Bestätigung `System_Auto = TRUE`
4. Bestätigung, dass alle Freigaben wahr sind
5. Begrenzung auf technische Min/Max-Werte
6. Anwendung der ROC-Begrenzung
7. Schreiben auf `Actual_Drive_Speed_Command`
8. Abschaltung oder Sperrung, falls Sicherheitskette offen

Was sollte die SPS-Logik erzwingen, bevor ein KI-Befehl weitergeleitet wird?

Die SPS sollte dieselben Dinge erzwingen, die ein vorsichtiger Inbetriebsetzungsingenieur vor dem Einschalten der Anlage prüfen würde:

• Ist die Maschine im korrekten Modus?
• Ist die Sequenz im korrekten Schritt?
• Sind alle Freigaben erfüllt?
• Sind die Rückmeldungen gesund?
• Liegt der angeforderte Wert innerhalb der physikalischen Grenzen?
• Ist die angeforderte Änderung für diesen Prozess plausibel?
• Gibt es eine aktive Abschaltung oder Sicherheitsbedingung?

Die letzte Frage ist oft wichtiger als das Architekturdiagramm.

Die Master-Not-Halt-Kette

Die Master-Not-Halt-Kette muss außerhalb der KI-Autoritätsgrenze liegen, da das Not-Halt-Verhalten nicht von der Inferenzqualität, dem Netzwerk-Timing oder dem Zustand der übergeordneten Software abhängen darf.

In der Praxis:

• Der Not-Halt-Pfad sollte festverdrahtet oder in einer zertifizierten Sicherheitsfunktion gemäß Anwendungsanforderung behandelt werden.
• Das KI-System sollte weder in den Not-Halt-Zustand schreiben noch diesen unterdrücken.
• Die Standard-Steuerungsaufgabe kann den Not-Halt-Zustand beobachten, sollte aber nicht dessen alleiniger Wächter sein.
• Jeder KI-angeforderte Befehl muss harmlos zusammenbrechen, wenn die Not-Halt-Kette öffnet.

Eine nützliche Regel lautet: Wenn ein Netzwerk-Hickup, ein Modellfehler oder ein Parser-Fehler die Bewegung aktiviert lassen kann, ist das Design nicht fertig.

Sie testen es, indem Sie anormale Befehle injizieren und beweisen, dass die SPS-Reaktion unter diesen Bedingungen begrenzt, beobachtbar und korrekt bleibt.

Hier hören viele Teams zu früh auf. Ein sauberer Nominal-Lauf beweist fast nichts.

Testen Sie mindestens diese Fälle:

• KI-Anfragen oberhalb des maximal zulässigen Wertes
• KI-Anfragen unterhalb des minimal zulässigen Wertes
• Abrupte Sprungänderungen über die sichere Rampenrate hinaus
• Befehle, die im falschen Maschinenzustand ausgegeben wurden
• Befehle, die ausgegeben wurden, während eine Freigabe falsch war
• Veraltete oder eingefrorene Upstream-Werte
• Oszillierende oder verrauschte Anfragesignale
• Not-Halt- oder Abschaltaktivierung während einer aktiven KI-Anfrage

Verifizieren Sie für jeden Fall:

• finaler Aktuatorbefehl,
• Alarmverhalten,
• Sequenzverhalten,
• Bediener-Sichtbarkeit,
• Wiederherstellungsverhalten nach Fehlerbehebung.

Ein Veto, das korrekt klemmt, aber die Sequenz in einem inkohärenten Zustand zurücklässt, ist nur eine halbe Lösung.

OLLA Lab ist hier als begrenzte Validierungsumgebung nützlich, in der Ingenieure fehlerhafte Befehle injizieren, die Reaktion der Ausrüstung beobachten und die Logik überarbeiten können, bevor physische Hardware involviert ist.

Diese Positionierung ist wichtig. OLLA Lab ist kein Sicherheitszertifizierer und kein Ersatz für eine formale Validierung auf der Zielplattform. Es ist eine praktische Umgebung, um risikoreiche Inbetriebsetzungslogik auf kontrollierte Weise zu proben.

Innerhalb von OLLA Lab können Ingenieure:

• Logik in einem webbasierten Editor erstellen,
• Simulationen ohne physische Hardware ausführen,
• Tags, I/O, Analogwerte und PID-relevante Variablen überwachen,
• szenariobasierte Ausrüstungsmodelle verwenden,
• den Logikzustand mit dem simulierten Maschinenverhalten vergleichen,
• die Logik nach Beobachtung eines Fehlerfalls überarbeiten.

Für den Anwendungsfall dieses Artikels ist der Workflow unkompliziert:

1. Erstellen Sie ein Zwischen-Tag wie `AI_Requested_Speed`
2. Leiten Sie dieses Tag durch die Begrenzungs- und Freigabelogik
3. Beobachten Sie den resultierenden `Actual_Drive_Speed_Command`
4. Injizieren Sie anormale Werte oder instabile Muster
5. Bestätigen Sie, dass das simulierte Motor-, Pumpen- oder Ventilmodell niemals sichere Grenzen überschreitet
6. Überprüfen Sie Alarme und überarbeiten Sie die Logik

Hier wird OLLA Lab operativ nützlich. Man kann nicht verantwortungsvoll einen halluzinierten 200%-Ventil-Öffnungsbefehl an einem Live-Prozess-Skid testen, nur um zu sehen, was passiert. Neugier ist wertvoll; verbogene Hardware ist teuer.

Was „Simulationsbereit“ in der Praxis bedeutet

Ein Ingenieur ist simulationsbereit, wenn er all dies in einer virtuellen Umgebung tun kann:

• Ursache-Wirkung vom Eingang zum Ausgang nachverfolgen,
• beobachten, ob eine Freigabe oder Verriegelung die Ausführung blockiert hat,
• die exakte Sprosse oder Bedingung identifizieren, die die Reaktion erzeugt hat,
• den Steuerungslogikzustand mit dem simulierten Ausrüstungszustand vergleichen,
• einen Fehler injizieren und das resultierende Verhalten erklären,
• die Logik überarbeiten und erneut testen, bis die Reaktion begrenzt und wiederholbar ist.

Das ist die Schwelle, auf die es bei der Inbetriebsetzungsvorbereitung ankommt. Nicht „kann einen Timer-Befehl platzieren“, sondern „kann beweisen, warum die Maschine sich bewegt hat oder nicht“.

Das richtige Artefakt ist ein kompakter Bestand an technischen Nachweisen, keine Screenshot-Galerie.

Verwenden Sie diese Struktur:

Geben Sie an, was akzeptables Verhalten in beobachtbaren Begriffen bedeutet: zulässiger Bereich, gültige Zustände, erwartete Alarmreaktion, Abschaltverhalten und Wiederherstellungsverhalten.

Dokumentieren Sie den exakten anormalen Eingang: Überschreitungsanfrage, ungültiger Zustandsbefehl, veraltetes Tag, verrauschtes Signal oder Not-Halt während der Bewegung.

Zeichnen Sie auf, was sich in der Logik geändert hat: Begrenzung hinzugefügt, Freigabe verschärft, Timeout eingeführt, Alarm gespeichert, ROC-Grenze angepasst.

1. Systembeschreibung Definieren Sie die Maschine oder Prozesszelle, die Regelgröße, die Betriebsmodi und die relevante Sicherheitsgrenze.
2. Operative Definition von „korrekt“
3. SPS-Logik und simulierter Ausrüstungszustand Zeigen Sie die Steuerungslogik neben der simulierten Aktuator- oder Prozessreaktion, damit die Kausalkette sichtbar ist.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung
6. Gelernte Lektionen Geben Sie an, was der Fehler aufgedeckt hat und welche Designregel nun daraus folgt.

Dies erzeugt Nachweise, die ein anderer Ingenieur überprüfen, hinterfragen und reproduzieren kann. Das ist der Standard, den man anstreben sollte.

Der häufigste Fehler ist es, der KI zu erlauben, die Verifizierungsschicht zu umgehen.

Weitere wiederkehrende Fehler sind:

• KI-Ausgabe direkt in Aktuator-Befehls-Tags schreiben,
• durchschnittliche KI-Leistung als Sicherheitsargument behandeln,
• Erkennung veralteter Daten vergessen,
• zustandsbasierte Freigaben weglassen,
• sich auf HMI-Alarme statt auf harte Ausführungsblöcke verlassen,
• zu viel Vertrauen in die Simulation ohne plattformspezifische finale Validierung,
• generierte Logik mit validierter Logik verwechseln.

Eine generierte Sprosse ist keine bewährte Sprosse. Industrielle Steuerung wird immer noch davon bestimmt, was die Maschine tatsächlich tut.

Das korrekte Muster lautet nicht „KI steuert die Anlage“. Das korrekte Muster lautet „KI darf vorschlagen, aber die SPS entscheidet, und die Sicherheitsebene kann immer noch Nein sagen“.

Ein deterministisches Veto ist der technische Mechanismus, der diese Grenze real macht. Es wandelt unbegrenzte Anfragen durch Begrenzungen, Freigaben, Verriegelungen und unabhängige Sicherheitsfunktionen in begrenztes Steuerungsverhalten um. So verhindern Sie, dass probabilistische Software zu einem physischen Vorfall wird.

OLLA Lab passt in diesen Workflow als Proben- und Validierungsumgebung. Es ermöglicht Ingenieuren, die unangenehmen Fälle zu üben – schlechte Sollwerte, ungültige Zustände, verrauschte Signale, fehlgeschlagene Freigaben, Not-Halte –, ohne die Live-Ausrüstung als Testbank zu benutzen. Das ist ein glaubwürdigerer Weg zur Inbetriebsetzungskompetenz, als Syntax auswendig zu lernen und zu hoffen, dass der erste echte Fehler glimpflich verläuft.

Dieser Artikel wurde von Experten für industrielle Automatisierung und funktionale Sicherheit verfasst, die sich auf die Integration von KI in deterministische Steuerungsumgebungen spezialisiert haben.

Die technischen Konzepte basieren auf den Standards IEC 61508 und ISO 13849. Die Simulationsdaten beziehen sich auf interne Validierungstests von Ampergon Vallis (Q1 2026).

- 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)