So trennen Sie KI-Perzeption von der SPS-Sicherheit: Die „Medulla Oblongata“-Architektur

Die „Medulla Oblongata“-Architektur trennt nicht-deterministische KI-Perzeption von deterministischer SPS-Steuerung. In diesem Modell kann die KI Sollwerte oder Klassifizierungen vorschlagen, aber die SPS bleibt die harte Echtzeit-Validierungs- und Ausführungsschicht, die Grenzwerte, Freigaben, Watchdogs und das Verhalten im sicheren Zustand erzwingt, bevor ein Befehl die Anlage erreicht.

KI ist keine Sicherheitssteuerung, und sie wie eine solche zu behandeln, ist ein architektonischer Fehler, noch bevor es zu einem Inbetriebnahmefehler wird. Die nützliche Unterscheidung ist einfach: KI ist gut in Perzeption, Schätzung und Optimierung; SPSen sind gut in deterministischer Ausführung, Verriegelungen und begrenzter Steuerung.

Diese Unterscheidung ist wichtig, da industrielle Steuerungssysteme nicht abstrakt ausfallen. Sie fallen aus als verpasste Heartbeats, veraltete Werte, Race Conditions und Ausgänge, die sich bewegen, wenn sie es nicht sollten. Die Maschine ist selten von einem cleveren Modell beeindruckt.

Ein kürzlich durchgeführter interner Bench-Test bei Ampergon Vallis stützt den praktischen Wert dieser Trennung. Während einer 100-stündigen Simulationsübung in OLLA Lab führten asynchrone externe Sollwert-Updates in einem Regelkreis-Szenario zu einem Anstieg der Integral-Windup-Fehlerereignisse um 14 % im Vergleich zu einem SPS-Validierungspfad mit Begrenzung und Ratenlimitierung, während der SPS-gesteuerte Pfad die Antwortvarianz auf ein deterministisches 3-ms-Ausführungsfenster für die Validierungs-Rung-Sequenz begrenzte. [Methodik: 100-stündiger simulierter Testlauf; Aufgabe = Übergabe externer Sollwerte in ein begrenztes Steuerungsszenario; Basis-Vergleichswert = direkte asynchrone Sollwerteinspeisung ohne Begrenzungs- und Watchdog-Validierung; Zeitfenster = ein einzelner kontinuierlicher 100-Stunden-Lauf.] Diese Metrik stützt den Wert einer defensiven SPS-Validierung in der Simulation. Sie stützt keine allgemeine Aussage über alle KI-Systeme, alle Anlagen oder formale Sicherheitszertifizierungen.

Eine deterministische Ausführung ist erforderlich, da Sicherheits- und primäre Steuerungsentscheidungen innerhalb bekannter Zeitgrenzen erfolgen müssen. KI-Inferenz-Engines, ob lokal oder remote, garantieren diese Eigenschaft nicht.

Eine SPS führt ihr Programm in einem begrenzten Zyklus (Scan Cycle) aus. Eingänge werden gelesen, Logik wird gelöst, Ausgänge werden geschrieben und der Zyklus wiederholt sich in einem definierten Intervall. Dieses Intervall kann je nach Plattform und Programmlast leicht variieren, ist aber so ausgelegt, dass es vorhersehbar und beobachtbar bleibt. Vorhersehbarkeit ist der entscheidende Punkt.

KI-Systeme arbeiten anders. Ihre Antwortzeit kann mit Prozessorlast, Speicherauslastung, Scheduler-Verhalten, Modellgröße, thermischer Drosselung, Middleware-Verzögerungen oder Netzwerklatenz variieren. Selbst wenn die durchschnittliche Inferenz schnell ist, ist das Worst-Case-Timing entscheidend, wenn sich Ausrüstung bewegen, kollidieren, überlaufen, überhitzen oder nicht abschalten kann.

Die Mathematik des Scan-Zyklus versus asynchrone Inferenz

Die technische Unterscheidung ist nicht philosophisch. Sie ist zeitlich.

• SPS-Steuerungspfad
• Ausführung in einem wiederholten Scan-Zyklus
• Unterstützt begrenzte Logikauswertung
• Ist für deterministische E/A-Verarbeitung ausgelegt
• Kann hinsichtlich Timing und Fehlerverhalten auditiert werden

• KI-Rechenpfad
• Ausführung asynchron
• Kann Ergebnisse in unregelmäßigen Intervallen liefern
• Kann hängen bleiben, Zeitüberschreitungen aufweisen, Jitter erzeugen oder veraltete Ausgaben liefern
• Hängt oft von Software-Stacks ab, die nicht als primäre Sicherheitslogik konzipiert sind

In der Praxis kann man einer SPS vertrauen, dass sie bei jedem Scan eine Freigabe prüft. Ein KI-Dienst kann nützlich sein, aber ihm kann nicht auf die gleiche Weise vertraut werden. Nützlich und vertrauenswürdig sind keine Synonyme. Anlagen lernen diese Unterscheidung auf teure Weise, wenn sie sie vergessen.

Was Normen über deterministische Steuerung sagen

IEC 61508 etabliert den Rahmen für funktionale Sicherheit für elektrische, elektronische und programmierbare elektronische sicherheitsbezogene Systeme. Eine zentrale Implikation für diese Diskussion ist eindeutig: sicherheitsbezogenes Verhalten erfordert nachweisbare, begrenzte und validierte Ausführungseigenschaften.

Das bedeutet nicht, dass jedes SPS-Programm automatisch sicher ist. Es bedeutet, dass Sicherheitsfunktionen ein deterministisches Design, eine Verifizierung und eine Lebenszyklusdisziplin erfordern, die asynchrone KI-Systeme nicht von Natur aus bieten. exida und verwandte Leitfäden zur funktionalen Sicherheit machen den gleichen praktischen Punkt in der Industrie deutlich: Wenn eine Funktion sicherheitskritisch ist, sind Timing-Unsicherheit und nicht verifizierbares Verhalten keine geringfügigen Unannehmlichkeiten.

Eine prägnante Korrektur ist hier nützlich: KI kann ein sicherheitsbezogenes System unterstützen, sollte aber nicht als primäre deterministische Sicherheitsschicht behandelt werden. Man kann keinen Lichtvorhang an ein LLM anschließen und das Architektur nennen.

Die „Medulla Oblongata“-Architektur ist ein geschichtetes Steuerungsmodell, bei dem die KI vorschlägt und die SPS entscheidet. Die KI führt eine übergeordnete Perzeption oder Optimierung durch; die SPS bleibt die harte Echtzeit-Autorität, die diese Anforderungen validiert, begrenzt, sequenziert oder ablehnt, bevor die Hardware reagiert.

Die biologische Analogie ist einprägsam, weil sie strukturell genau genug ist, um nützlich zu sein. Der Kortex interpretiert und plant. Die Medulla kümmert sich um autonome Überlebensfunktionen. In der Automatisierung ausgedrückt: Die KI kann die Produktqualität schätzen, Objekte erkennen oder eine Anpassung der Zuführrate vorschlagen; die SPS behält die Kontrolle über Verriegelungen, Stoppketten, Freigaben und begrenzte Betätigung.

Die Hierarchie der Steuerung

• Interpretiert Bilder, Trends oder multivariablen Prozesskontext
• Generiert eine Klassifizierung, Empfehlung oder einen angeforderten Sollwert
• Arbeitet asynchron und kann falsch, verzögert oder veraltet sein

• Prüft die Anforderung gegen harte Grenzwerte
• Verifiziert Maschinenzustand, Freigaben und Verriegelungen
• Bestätigt Aktualität durch Heartbeat- oder Watchdog-Logik
• Wendet Änderungsratenbegrenzungen, Klemmen und Fallback-Verhalten an

• Empfängt nur von der SPS genehmigte Befehle
• Beinhaltet Antriebe, Ventile, Schütze, Aktoren und Alarme
• Wechselt in einen sicheren oder begrenzten Zustand, wenn die Validierung fehlschlägt

1. Perzeptionsschicht (KI)
2. Validierungsschicht (SPS)
3. Ausführungsschicht (Hardware)

Dies ist keine Anti-KI-Position. Es ist eine Pro-Grenzen-Position. Gute Architektur besteht größtenteils aus disziplinierter Ablehnung.

Was die SPS immer beibehalten muss

Die SPS muss die absolute Autorität über Funktionen behalten, die ein deterministisches Antwortverhalten und ein begrenztes Fehlerverhalten erfordern.

Dazu gehören typischerweise:

• Verarbeitung von Not-Aus-Signalen
• Auswertung von Sicherheitsverriegelungen
• Bewegungsfreigaben
• Kollisionsvermeidungslogik
• Harte Verfahr- oder Geschwindigkeitsbegrenzungen
• Fallback auf sicheren Zustand bei Kommunikationsverlust
• Sequenzsteuerung für gefährliche Übergänge
• Letztinstanzliche Befehlsarbitrierung an Aktoren

Wenn eine KI eine Geschwindigkeitserhöhung anfordert, kann die SPS diese erlauben, reduzieren, verzögern oder ablehnen. Die endgültige Entscheidung liegt bei der deterministischen Schicht.

Sie programmieren harte Echtzeit-Sicherheitsgrenzwerte, indem Sie KI-Ausgaben als nicht vertrauenswürdige externe Eingänge behandeln. Das bedeutet, dass jeder KI-generierte Wert eine explizite defensive Logik durchlaufen muss, bevor er eine Maschine oder einen Prozess beeinflussen kann.

Hier hört Kontaktplan auf, Syntax-Übung zu sein, und wird zu Inbetriebnahmekompetenz. Ein Rung (Strompfad), der nur „funktioniert“, reicht nicht aus. Der Rung muss auch kontrolliert ausfallen können.

Essenzielle defensive Rungs für das KI-SPS-Handshaking

#### 1. Watchdog-Timer zur Heartbeat-Überwachung

Ein Watchdog-Timer verifiziert, dass das KI- oder übergeordnete Rechensystem noch innerhalb eines akzeptablen Intervalls kommuniziert.

- Wenn der Timer abläuft, führt die SPS folgende Aktionen aus:

• Die KI sendet ein Heartbeat-Bit oder einen inkrementierenden Wert
• Die SPS setzt einen TON oder einen äquivalenten Timer zurück, wenn sich der Heartbeat ändert
• Ungültigerklärung der KI-Anforderung,
• Erzwingen eines sicheren Standardzustands,
• Auslösen eines Fehlers oder Alarms,
• und Verhindern weiterer Ausführung, bis Wiederherstellungsbedingungen erfüllt sind

Ein toter vorgelagerter Dienst sollte keinen aktiven Ausgangspfad hinterlassen. Das ist keine Intelligenz; das ist Rückstand.

#### 2. Limit-Baustein für harte Begrenzung

Eine Limit-Anweisung beschränkt angeforderte Werte auf ein physikalisch sicheres Betriebsband.

Beispiel-Anwendungsfälle:

• Begrenzung der angeforderten Motordrehzahl zwischen minimaler Kühlgeschwindigkeit und maximaler sicherer Drehzahl
• Begrenzung einer Ventilvorgabe auf einen Bereich, der hydraulische Schläge vermeidet
• Begrenzung eines Temperatursollwerts auf die Auslegungsgrenzen der Anlage

Beispiel für die Struktur im Kontaktplan:

- Anweisung: LIM (Grenzwerttest) - Untergrenze: 15,0 Hz - Test: `KI_Angeforderte_Geschwindigkeit` - Obergrenze: 45,0 Hz - Ausgang: `Sichere_Geschwindigkeitsfreigabe`

Es geht nicht um Eleganz. Es geht darum, dass kein vorgelagerter Optimismus eine Übergeschwindigkeit befehlen kann.

#### 3. Begrenzung der Änderungsrate

Ein Änderungsratenbegrenzer verhindert abrupte Befehlsänderungen, die zwar dem Betrag nach technisch gültig, aber im Übergang unsicher sind.

Beispiele:

• Verhindern, dass ein Ventil in einem Update von 10 % auf 100 % springt
• Begrenzung von Frequenzumrichter-Drehzahlsteigerungen auf eine definierte Rampe
• Begrenzung der Sollwertbewegung pro Scan oder pro Sekunde

Dies ist wichtig, da viele Fehler beim Übergang auftreten, nicht am Endpunkt. Die endgültige Zahl mag legal sein, während der Weg dorthin leichtsinnig ist.

#### 4. Erkennung von Veraltung und Sequenzgültigkeit

Ein Wert kann numerisch plausibel und dennoch betrieblich ungültig sein.

Die SPS sollte verifizieren:

• Aktualität des Zeitstempels oder Sequenzzählers
• Kompatibilität des Maschinenmodus
• Aktuelle Betriebsphase
• Freigabestatus vor Anwendung der Anforderung
• Ob die Anforderung zum aktiven Rezept, Batch-Schritt oder Sequenzzustand gehört

Ein veralteter Sollwert während der falschen Sequenzphase ist nur eine höfliche Form von schlechten Daten.

Was „korrekt“ in dieser Architektur bedeutet

Korrektheit muss betrieblich definiert werden, nicht kosmetisch. In diesem Kontext bedeutet eine korrekte KI-SPS-Integration:

• die SPS akzeptiert nur frische und begrenzte Anforderungen,
• die Maschine bewegt sich nur, wenn Freigaben wahr sind,
• unsichere Übergänge werden blockiert,
• Kommunikationsverlust erzeugt einen definierten Fallback-Zustand,
• und jeder Ablehnungspfad ist in Tags, Alarmen oder Ereignislogik beobachtbar.

Diese Definition ist nützlicher als „der Rung wurde kompiliert“. Kompilierung ist eine niedrige Hürde. Anlagenschäden überspringen sie regelmäßig.

Sie validieren das KI-SPS-Handshaking, indem Sie abnormales Verhalten gezielt simulieren und dann beweisen, dass die SPS-Logik es ablehnt oder eindämmt. Validierung bedeutet nicht zu zeigen, dass der Idealpfad funktioniert. Validierung bedeutet zu zeigen, dass schlechte Eingaben sicher und beobachtbar fehlschlagen.

Hier benötigt Simulation-Ready eine strenge Definition. Ein Simulation-Ready-Ingenieur ist jemand, der Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor sie einen Live-Prozess erreicht. Das ist ein höherer Standard als das Kennen der Kontaktplan-Syntax. Es ist der Unterschied zwischen dem Zeichnen von Logik und deren Inbetriebnahme.

Was vor der Hardware-Exposition getestet werden sollte

Ingenieure sollten mindestens Folgendes testen:

• verlorener Heartbeat vom KI-Dienst
• verzögerte Updates und veraltete Werte
• Sollwerte außerhalb des Bereichs
• unplausible, aber innerhalb des Bereichs liegende Werte
• schnelle oszillierende Anforderungen
• Modus-Fehlanpassung zwischen KI-Anforderung und Maschinenzustand
• schlechtes Timing der Startsequenz
• Fallback-Verhalten nach Wiederherstellung der Kommunikation

Wenn diese Fälle nicht durchgespielt wurden, ist die Architektur nicht validiert. Sie ist lediglich hoffnungsvoll.

OLLA Lab ist hier als begrenzte Validierungsumgebung nützlich, um die SPS-Seite des KI-Integrationsrisikos zu proben. Es ist kein KI-Sicherheitszertifizierer und kein Ersatz für formale Standortabnahme, Gefahrenanalyse oder Bewertung der funktionalen Sicherheit. Es ist ein Ort, um genau die Aufgaben der Steuerungshärtung zu üben, die zu riskant oder zu teuer sind, um sie an Live-Ausrüstung zu improvisieren.

Der praktische Vorteil ist einfach: Ingenieure können schlechtes Verhalten sicher und wiederholt einspeisen.

Was OLLA Lab Ingenieuren zur Probe ermöglicht

Mit dem webbasierten Kontaktplan-Editor, dem Simulationsmodus und dem Variablen-Panel können Ingenieure:

• Kontaktplan-Logik erstellen, die einen externen angeforderten Wert überwacht,
• Eingänge und interne Tags in Echtzeit umschalten,
• Ausgänge und Zwischenfreigaben beobachten,
• Timer, Zähler, Komparatoren, Mathematik und PID-bezogenes Verhalten testen,
• den Kontaktplan-Zustand gegen die simulierte Anlagenreaktion vergleichen,
• und die Logik nach Beobachtung eines Fehlerpfads überarbeiten.

Dieser Workflow ist wichtig, da KI-Integrationsfehler oft als Timing- und Zustandsprobleme auftreten, nicht nur als falsche Zahlen. OLLA Lab gibt diesen Problemen einen Ort, an dem sie sichtbar werden.

Ein praktischer Validierungs-Workflow in OLLA Lab

Eine glaubwürdige Probesequenz sieht so aus:

• Bauen Sie eine Rung-Sequenz, die einen externen angeforderten Geschwindigkeits-, Durchfluss- oder Positionswert empfängt
• Fügen Sie Freigaben, Modus-Prüfungen und eine endgültige Ausführungsbedingung hinzu

• Fügen Sie einen Watchdog-Timer ein
• Fügen Sie eine Begrenzung mittels Limit-Logik hinzu
• Fügen Sie einen Ratenbegrenzer oder eine schrittweise Rampe hinzu
• Definieren Sie das Fallback-Verhalten bei Timeout oder ungültigen Daten

• Verwenden Sie das Variablen-Panel, um Werte außerhalb des Bereichs zu erzwingen
• Pausieren oder stoppen Sie das Heartbeat-Signal
• Führen Sie abrupte Befehlsänderungen ein
• Wechseln Sie den Prozesszustand mitten im Befehl

• Bestätigen Sie, dass Ausgänge begrenzt bleiben
• Verifizieren Sie, dass die Timeout-Logik korrekt auslöst
• Prüfen Sie, ob Alarme oder Fehlerbits sichtbar werden
• Vergleichen Sie das simulierte Anlagenverhalten mit der erwarteten Steuerungsphilosophie

• Passen Sie Timer-Werte, Grenzwerte und Sequenzbedingungen an
• Testen Sie dieselben Fehler erneut, bis der Ablehnungspfad deterministisch und lesbar ist

1. Erstellen des Steuerungspfads
2. Hinzufügen defensiver Logik
3. Einspeisen abnormaler Fälle
4. Beobachten von Ursache und Wirkung
5. Überarbeiten und erneut ausführen

Hier wird OLLA Lab betrieblich nützlich. Es lässt Ingenieure Veto-Logik proben, nicht nur bewundern.

Sie sollten einen kompakten Satz an technischen Nachweisen erstellen, der die Steuerungslogik unter Fehlerbedingungen demonstriert, nicht eine Galerie von Editor-Screenshots. Screenshots beweisen, dass ein Bildschirm existierte. Sie beweisen nicht, dass die Logik unter Stress standhielt.

Verwenden Sie diese Struktur:

Geben Sie die genauen Akzeptanzkriterien an: zulässiger Betriebsbereich, Timeout-Intervall, Freigabebedingungen, Fallback-Zustand und erwartetes Alarmverhalten.

Dokumentieren Sie die eingeführte abnormale Bedingung: veralteter Heartbeat, Übergeschwindigkeitsanforderung, Modus-Fehlanpassung, oszillierender Befehl oder ungültiges Sequenz-Timing.

Erklären Sie, was sich in der Logik geändert hat: Begrenzung hinzugefügt, Watchdog-Intervall geändert, Verriegelung eingefügt, Änderungsratenbegrenzung hinzugefügt oder Sequenzsteuerung überarbeitet.

1. Systembeschreibung Beschreiben Sie die Maschine oder Prozesszelle, das Steuerungsziel, den KI-bereitgestellten Eingang und die SPS-eigene Sicherheits- oder Validierungsrolle.
2. Betriebliche Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die relevanten Rungs, Tags und den simulierten Maschinen- oder Prozesszustand, den diese Rungs steuern.
4. Der eingespeiste Fehlerfall
5. Die vorgenommene Überarbeitung
6. Gelernte Lektionen Geben Sie an, was der Fehler über die Steuerungsphilosophie, Maschinenannahmen oder den Datenvaliditätspfad offenbart hat.

Diese Nachweisstruktur ist weitaus überzeugender als ein polierter Demo-Clip. Inbetriebnahmerisiken reagieren auf Beweise, nicht auf Ästhetik.

KI gehört der deterministischen Steuerung vorgelagert, nicht an deren Stelle. Ihre nützliche Rolle besteht darin, beratende oder Kandidatenwerte aus komplexen Daten zu generieren, die konventionelle Logik schlecht handhabt.

Beispiele sind:

• bildbasierte Klassifizierung
• Anomalieerkennung
• Qualitätsschätzung
• Scoring für vorausschauende Wartung
• Empfehlungen für multivariable Optimierung
• adaptive Sollwertvorschläge

Die SPS entscheidet dann, ob diese Ausgaben im aktuellen Maschinenkontext zulässig sind.

Eine saubere architektonische Regel

Eine praktische Regel lautet: KI darf empfehlen; die SPS muss autorisieren.

Diese Regel bewahrt die Stärken beider Schichten:

• KI handhabt Mehrdeutigkeit, Mustererkennung und Optimierung
• SPS-Logik handhabt Timing, Freigaben, Grenzwerte und deterministische Ausführung

Das Ergebnis ist nicht glamourös, was in der Steuerungstechnik oft ein gutes Zeichen ist. Gute Anlagenarchitektur sieht meist ein wenig langweilig aus, bis sie einen teuren Fehler verhindert.

Der häufigste Fehler ist es, KI-Ausgaben die explizite Validierungslogik umgehen zu lassen. Sobald das passiert, hat die Architektur bereits ihre Grenzdisziplin verloren.

Weitere wiederkehrende Fehler sind:

• einen Netzwerk-Zeitstempel als äquivalent zu deterministischer Aktualität zu behandeln
• anzunehmen, dass Werte innerhalb des Bereichs automatisch sicher sind
• die Validierung des Sequenzzustands zu vergessen
• das Fallback-Verhalten bei Heartbeat-Verlust wegzulassen
• beratende Ausgaben im Laufe der Zeit zu direkten Befehlen werden zu lassen
• nur nominales Verhalten zu testen und nicht abnormale Übergänge
• Simulator-Erfolg mit Standortreife zu verwechseln

Letzteres verdient Betonung. Simulation ist eine Validierungsumgebung, keine Erklärung der Feldkompetenz. Es ist der Ort, an dem Ingenieure lernen, Logik zu beobachten, zu diagnostizieren und zu härten, bevor sie live eingesetzt wird. Nützlich, notwendig und dennoch nicht dasselbe, wie um 2:00 Uhr morgens neben einer laufenden Linie zu stehen, während die Instandhaltung wartet.

Der sichere Weg, KI in die industrielle Automatisierung zu integrieren, besteht darin, Perzeption von Autorität zu trennen. KI kann klassifizieren, schätzen und empfehlen. Die SPS muss der harte Echtzeit-Kern bleiben, der validiert, begrenzt, sequenziert und sein Veto einlegt.

Das ist die „Medulla Oblongata“-Architektur in einem Satz: die KI denkt, die SPS hält den Organismus am Leben.

Für Ingenieure besteht die praktische Aufgabe nicht darin, KI-Ausgaben zu feiern, sondern den Steuerungspfad um sie herum zu härten. Watchdogs, Grenzwerte, Freigaben, Änderungsratenprüfungen, Erkennung veralteter Daten und Fallbacks für sichere Zustände sind keine optionalen Details. Sie sind die Architektur.

Und wenn das weniger futuristisch klingt als die Marketing-Folien, gut. Maschinen bevorzugen im Allgemeinen Erwachsene.

- IEC 61131-3: Programmierbare Steuerungen — Teil 3 - IEC 61508 Normenfamilie für funktionale Sicherheit - exida Ressourcen für funktionale Sicherheit und Validierung - NAMUR NE 107 Empfehlung zur Statusmeldung - Digitaler Zwilling in der Industrie: Stand der Technik (DOI)