KI-Inferenz in einer SPS ausführen: Validierung neuronaler Netze mit OLLA Lab

Die Ausführung von KI-Inferenz in der Fertigung erfordert die Umwandlung probabilistischer Modellausgaben in begrenztes, deterministisches SPS-Verhalten. Eine sichere Implementierung hängt von IEC 61131-3-kompatibler Logik, Scan-Zeit-Disziplin, Ausgangsbeschränkungen und der simulierten Validierung physikalischer Konsequenzen ab, bevor eine Inbetriebnahme oder ein Live-Einsatz erfolgt.

KI-Inferenz in einer SPS ist nicht unmöglich, wird aber meist falsch angegangen. Das eigentliche Problem ist nicht, ob eine Steuerung mathematische Berechnungen ausführen kann, die einem Modell ähneln, sondern ob diese Ausführung innerhalb einer industriellen Steuerungsaufgabe deterministisch, prüfbar, scan-sicher und betrieblich begrenzt bleibt.

Ein häufiges Missverständnis ist, dass „KI in einer SPS“ bedeutet, ein neuronales Netz direkt in die Kontaktplan-Logik (KOP) einzubetten und es entscheiden zu lassen. In der Praxis ist ein sinnvoller Einsatz enger gefasst: Ingenieure übersetzen trainiertes Verhalten in deterministische Anweisungen, begrenzen die Ausgänge und validieren das Ergebnis anhand des Prozessverhaltens, bevor es jemals eine reale Maschine sieht. Die Syntax ist einfach; die Bereitstellungsfähigkeit ist der aufwendige Teil.

Während interner Benchmark-Tests in der Simulationsumgebung OLLA Lab führte das Einspeisen roher, KI-generierter Sortierlogik in Standard-Trainingsprojekte zu einer Erhöhung der simulierten Scan-Zeiten um durchschnittlich 42 ms. Eine durch Yaga unterstützte Umgestaltung in eine zustandsorientierte Logik nach IEC 61131-3 reduzierte die zusätzliche Scan-Belastung in denselben Projekten auf unter 4 ms. Methodik: 12 Simulationsläufe über 3 Varianten der Förderband-Sortierung, Basis-Vergleichswert = manuell erstellte deterministische Steuerungssequenz, Zeitfenster = Testzyklus März 2026. Dies stützt eine spezifische Aussage zum Scan-Zeit-Risiko in simulierten Trainingsszenarien. Es beweist keine universelle Feldleistung über alle SPS-Plattformen, Firmware-Versionen oder Prozessklassen hinweg.

Der Konflikt ist architektonischer Natur. SPS sind auf deterministische Scan-Ausführung ausgelegt, während neuronale Netze auf probabilistischer Inferenz und Approximation basieren. Dies sind nicht nur unterschiedliche Programmierstile, sondern grundlegend verschiedene Steuerungsannahmen.

Eine Standard-SPS-Aufgabe liest Eingänge, führt Logik aus und schreibt Ausgänge in einer begrenzten Sequenz. Von dieser Sequenz wird erwartet, dass sie ausreichend reproduzierbar ist, um Timing-Analysen, Fehlerbehandlung und ein vorhersehbares Maschinenverhalten zu unterstützen. Neuronale Modelle hingegen werden geschätzt, weil sie aus Trainingsdaten generalisieren und Ausgaben aus gewichteten Approximationen erzeugen. Nützlich in der Analytik; problematisch in einer durch Watchdogs begrenzten Regelschleife.

Der Scan-Zyklus ist die erste harte Grenze

Inferenz ist im Vergleich zur konventionellen diskreten Steuerung rechenintensiv. Selbst kleine Modelle basieren auf wiederholten Multiply-Accumulate-Operationen, Schwellenwertvergleichen und Array-Verarbeitungen, die die Ressourcen der Steuerung belasten können.

In einer SPS-Umgebung entstehen dadurch mehrere Risiken:

- Scan-Zeit-Überschreitungen: Zusätzliche Berechnungen können die Aufgabenausführung über die Watchdog-Grenzwerte hinaus verzögern. - Jitter: Variable Ausführungspfade können die Timing-Konsistenz stören. - Prioritätsinterferenzen: Nicht kritische Inferenz kann Zeit beanspruchen, die für Verriegelungen, Sequenzierungen oder Alarmbehandlungen benötigt wird. - Reduzierte Diagnosefähigkeit: Aufgeblähte Logik ist schwieriger sprossenweise oder zeilenweise zu überprüfen.

Der Maschine ist es egal, ob der Code modern ist. Ihr ist wichtig, ob der Ausgang rechtzeitig ankommt.

IEC 61508 legt die Messlatte höher als „es scheint zu funktionieren“

Funktionale Sicherheit wird nicht durch plausibles Verhalten in einem Nominalfall erfüllt. Die IEC 61508 konzentriert sich auf systematische Fähigkeiten, Rückverfolgbarkeit und disziplinierte Lebenszykluskontrollen für sicherheitsbezogene Systeme (IEC, 2010). Das ist hier entscheidend, da KI-generierte Logik nicht allein deshalb prüfbar ist, weil sie kompiliert.

Wenn KI-unterstützte Logik eine sicherheitsrelevante Funktion beeinflusst, müssen Ingenieure nachweisen können:

• was die Logik tut,
• warum sie es tut,
• wie sie überprüft wurde,
• welche Annahmen sie begrenzen,
• und wie Fehlermodi identifiziert und kontrolliert wurden.

Eine Black-Box-Empfehlung ohne nachvollziehbare Begründung ist kein Sicherheitsnachweis. Es ist ein Haftungsrisiko mit guter Formatierung.

Was sind die drei kritischen Fehlermodi von rohem, KI-generiertem SPS-Code?

Die häufigsten Fehlermodi sind operativer, nicht philosophischer Natur:

1. Nicht-deterministische Ausführungszeit KI-generierte Schleifen, Array-Durchläufe oder bedingte Verzweigungen können eine Variabilität der Scan-Zeit einführen, die bei Echtzeitaufgaben inakzeptabel ist.
2. Speicherallokation und Missbrauch von Datenstrukturen Vorgeschlagener Code kann dynamische Speichermuster oder Array-Größen voraussetzen, die nicht den Grenzen der Steuerung entsprechen, insbesondere bei älteren oder ressourcenbeschränkten SPS.
3. Zustandsdivergenz vom E/A-Modell Logik kann versuchen, Ausgänge oder interne Zustände auf eine Weise zu schreiben, die mit der normalen Eingangs-Scan-Ausführungs-Ausgangs-Sequenz der SPS in Konflikt steht, was zu Race-Conditions oder inkohärenten Maschinenzuständen führt.

Dies sind keine exotischen Randfälle. Das passiert, wenn Software-Annahmen in die industrielle Steuerung eindringen, ohne sich vorzustellen.

Der praktische Weg ist die Übersetzung, nicht die Transplantation. Ingenieure führen normalerweise kein vollständiges neuronales Framework innerhalb einer SPS aus. Sie glätten das erforderliche Inferenzverhalten in Standardanweisungen, die die Steuerung vorhersehbar ausführen kann.

Das bedeutet meist, ein trainiertes Modell in begrenzte Arithmetik, Vergleichslogik, Nachschlagetabellen oder vereinfachte Zustandslogik umzuwandeln, die in Strukturierter Text (ST), Funktionsbausteinsprache (FBS) oder, wo angemessen, in Kontaktplan-Logik (KOP) implementiert wird, unterstützt durch mathematische und Vergleichsoperationen.

Was bedeutet „KI-Inferenz in einer SPS“ operativ?

In diesem Kontext bedeutet KI-Inferenz in einer SPS die Ausführung einer begrenzten Approximation der Entscheidungslogik eines trainierten Modells unter Verwendung deterministischer Steuerungsanweisungen, die zeitlich abgestimmt, überprüft, getestet und gegen das Prozessverhalten begrenzt werden können.

Diese Definition schließt eine Menge Marketing-Nebel aus. Sie macht auch die Ingenieursaufgabe klarer.

Wie werden Modellgewichte in Strukturierten Text konvertiert?

Eine gängige Methode ist der Export trainierter Parameter aus einer externen Umgebung wie Python, gefolgt von der Hardcodierung des reduzierten Inferenzpfades in SPS-kompatible Arrays und arithmetische Operationen.

Typische Schritte sind:

• Training des Modells außerhalb der SPS-Umgebung,
• Reduzierung des Modells auf die kleinstmögliche Struktur,
• Export von Gewichten und Schwellenwerten,
• Codierung als feste Arrays oder Konstanten,
• Implementierung von Multiply-Add-Operationen in ST,
• Anwendung von Schwellenwert- oder Klassifizierungslogik,
• Begrenzung (Clamping) des Ergebnisses, bevor es eine nachgelagerte Steuerungsfunktion berührt.

Ein minimales Beispiel sieht so aus:

Sprache: Strukturierter Text

// Yaga-optimiertes Inferenz-Array für Anomalieerkennung FOR i := 0 TO 9 DO Accumulator := Accumulator + (SensorInput[i] * WeightMatrix[i]); END_FOR; IF Accumulator > Threshold THEN Anomaly_Detected := TRUE; END_IF;

Dies ist keine vollständige neuronale Laufzeitumgebung. Genau das ist der Punkt. Das Ziel ist kontrollierbares Inferenzverhalten, kein „Computational Theater“.

Wie hilft Yaga Assistant bei der Code-Übersetzung?

Yaga ist am besten als kontextbewusster Labor-Coach zu verstehen, nicht als autonomer Steuerungsingenieur. Innerhalb von OLLA Lab hilft es Benutzern, algorithmische Absichten auf höherer Ebene in Standard-Kontaktplan-Logik oder ST-Muster abzubilden, die sie inspizieren und testen können.

Seine nützliche Rolle ist begrenzt:

• Erklären, wie ein modellähnlicher Entscheidungspfad mit `MUL`, `ADD`, `CMP`, Timern und Zustandslogik dargestellt werden kann,
• Identifizieren von Logikmustern, die Race-Conditions oder unnötige Scan-Last erzeugen könnten,
• Auffordern des Benutzers, beratende Logik von Logik mit Ausgangsbefugnis zu trennen,
• Unterstützung bei der Umgestaltung generierten Codes in lesbarere und prüfbare Strukturen.

Das ist eine Validierungshilfe, kein Ersatz für technisches Urteilsvermögen. Die Unterscheidung ist wichtig.

KI-vorgeschlagene Logik ist zum Zeitpunkt der Generierung nicht vertrauenswürdig. Sie wird erst nach deterministischer Überprüfung, begrenzter Implementierung und simulierter Validierung gegen das Prozessverhalten nutzbar.

Dies ist der Kern-Workflow:

1. Generieren einer Kandidaten-Logikstruktur oder Übersetzung.
2. Umgestalten in steuerungseigene, lesbare Anweisungen.
3. Begrenzen aller Ausgänge und Zwischenzustände.
4. Simulieren von E/A, Sequenz-Timing und anormalen Bedingungen.
5. Beobachten der Scan-Zeit-Auswirkungen und des Zustandsverhaltens.
6. Überarbeiten, bis die Logik deterministisch, erklärbar und betrieblich akzeptabel ist.

Diese Schleife ist langsamer als Copy-Paste-Bereitstellung. Aber so bleiben Maschinen betriebsbereit.

Wie sollten Ingenieure KI-generierte Ausgänge begrenzen?

Jeder KI-abgeleitete Ausgang muss begrenzt werden, bevor er eine reale Steuerungsaktion beeinflusst. In OLLA Lab bietet das Variablen-Panel eine praktische Möglichkeit, Tags zu beobachten, Werte anzupassen und das Clamping-Verhalten unter Simulation zu testen.

Typische Begrenzungen umfassen:

• Minimum- und Maximum-Sollwertgrenzen,
• Änderungsratenbegrenzungen,
• Totzonen,
• Freigabeprüfungen,
• ausfallsichere Fallback-Werte,
• manuelle Modus-Übersteuerung,
• Alarm- und Auslöseschwellen unabhängig vom KI-Pfad.

Wenn beispielsweise eine abgeleitete Optimierungsroutine einen Drucksollwert vorschlägt, sollte der Ingenieur negative Werte, übermäßige Sprünge oder Befehle außerhalb des Prozessdesign-Umfangs verhindern. Ein PID-Regler akzeptiert Unsinn mit perfektem Gehorsam, es sei denn, man stoppt ihn vorher.

Was bewirkt Yagas Coaching-Workflow, bevor eine Spule erregt wird?

Die nützliche Disziplin ist die Validierung vor der Verriegelung. Bevor KI-beeinflusste Logik einen Ausgang steuern darf, kann Yaga den Benutzer anleiten, Folgendes zu verifizieren:

• Freigaben sind wahr,
• Auslösungen sind klar,
• Rückmeldungen sind gültig,
• Moduswahl ist korrekt,
• Ausgangsbegrenzungen sind aktiv,
• und das Verhalten bei anormalen Zuständen ist definiert.

Dies hält den KI-Beitrag nachgelagert zur deterministischen Veto-Logik. Ein gutes Steuerungssystem kann beratende Intelligenz akzeptieren. Es sollte die Autorität jedoch nicht an sie abtreten.

Die virtuelle Inbetriebnahme ist der sichere Ort, um zu entdecken, dass eine clevere Idee zu schwer für die Steuerungsaufgabe ist. OLLA Lab ist hier operativ nützlich, da es Benutzern ermöglicht, Logik zu erstellen, Simulationen auszuführen, Variablen zu inspizieren und den Zustand der Kontaktplan-Logik gegen das simulierte Anlagenverhalten zu vergleichen, bevor eine Live-Bereitstellung erfolgt.

Diese Produktpositionierung sollte begrenzt bleiben. OLLA Lab ist eine Proben- und Validierungsumgebung für risikoreiche Steuerungsaufgaben. Es ist kein Nachweis für Standortkompetenz, Zertifizierung oder Sicherheitsqualifikation durch Assoziation.

Was bedeutet „Simulation-Ready“ in diesem Kontext?

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

Operativ umfasst dies die Fähigkeit:

• Ursache und Wirkung vom Eingang zum Ausgang zu verfolgen,
• das Sequenzverhalten gegen die Steuerungsphilosophie zu verifizieren,
• Fehler einzuspeisen und die Reaktion zu beobachten,
• den Zustand der Kontaktplan-Logik mit dem simulierten Anlagenzustand zu vergleichen,
• Logik nach anormalen Bedingungen zu überarbeiten,
• und zu dokumentieren, was „korrekt“ bedeutet, bevor Inbetriebnahmedruck das Gespräch verzerrt.

Die Kontaktplan-Syntax zu kennen, reicht nicht aus. Eine Anlage nimmt keine Syntax in Betrieb.

Wie können Ingenieure einen virtuellen Watchdog überwachen?

In einer Simulationsumgebung können Ingenieure die Auswirkungen der Logikkomplexität auf das Ausführungsverhalten beobachten, ohne Hardware oder Prozesse zu gefährden. In OLLA Lab bedeutet dies zu testen, ob KI-beeinflusste Logik unter realistischen Szenariobedingungen sichtbare Verzögerungen, instabile Sequenzierungen oder Zustandsverzögerungen erzeugt.

Die relevanten Beobachtungen umfassen:

• verzögerte Spulenerregung,
• träge Sequenzübergänge,
• instabile Analogreaktion,
• Timer-Interaktionen unter höherer Logiklast,
• und Diskrepanzen zwischen erwarteter und simulierter Maschinenbewegung.

Ein virtueller Watchdog ist keine zertifizierte Sicherheitsfunktion. Er ist dennoch als Werkzeug für die Inbetriebnahme-Probe äußerst nützlich, da er Timing-Konsequenzen aufdeckt, bevor sie zu Feldausfällen werden.

Warum ist die Validierung durch digitale Zwillinge für KI-beeinflusste Logik wichtig?

Die Validierung durch digitale Zwillinge ist wichtig, weil Steuerungscode letztlich nach physikalischer Wirkung beurteilt wird, nicht nach interner Eleganz. Die 3D- und WebXR-fähigen Simulationen von OLLA Lab ermöglichen es Benutzern zu beobachten, wie Logikentscheidungen in realistischen industriellen Szenarien auf das Anlagenverhalten abgebildet werden.

Das ist wichtig, wenn verzögerte oder schlecht begrenzte Inferenz sichtbare Prozessfehler verursacht, wie zum Beispiel:

• ein pneumatischer Schieber, der zu spät auf einem Förderband ausfährt,
• eine oszillierende Haupt-/Reservepumpensequenz,
• eine HLK-Sequenz, die um einen Sollwert jagt,
• oder eine Prozessanlage, die in einen ungültigen Übergang eintritt, weil die abgeleitete Logik ihre Freigaben überholt hat.

Hier wird die Validierung durch digitale Zwillinge mehr als nur eine Phrase. Operativ bedeutet die Validierung durch digitale Zwillinge, Steuerungslogik gegen ein simuliertes Maschinen- oder Prozessmodell zu testen, um zu bestätigen, dass Sequenz-Timing, E/A-Verhalten, Verriegelungen, Alarme und physikalische Reaktionen mit der beabsichtigten Steuerungsphilosophie konsistent bleiben.

Forschungen im Bereich der simulationsbasierten Ingenieurwissenschaften und industrieller digitaler Zwillinge stützen konsistent den Wert virtueller Validierung zur Reduzierung von Unsicherheiten bei der Inbetriebnahme, zur Verbesserung des Verständnisses von Bedienern und Ingenieuren sowie zur Aufdeckung von Integrationsfehlern früher im Lebenszyklus (Tao et al., 2019; Jones et al., 2020; Fuller et al., 2020). Die Literatur ist breit gefächert und in der Terminologie uneinheitlich, aber die Richtung ist klar: Eine frühere Verhaltensvalidierung ist billiger als eine späte Entdeckung an der Live-Anlage. Das hat niemanden überrascht, der schon einmal um 2:00 Uhr morgens eine Linie neu starten musste.

Ein glaubwürdiger Nachweis ist um Systemverhalten, Fehlerbehandlung und Revisionslogik strukturiert. Screenshots allein sind ein schwacher Beweis, da sie den Schnittstellenzustand zeigen, nicht das technische Urteilsvermögen.

Verwenden Sie diese sechsteilige Struktur:

Geben Sie an, was korrektes Verhalten in beobachtbaren Begriffen bedeutet: Sequenzreihenfolge, Zeitfenster, Freigaben, Auslöseantwort, Analogbereich oder Klassifizierungsschwellenwert.

Führen Sie eine realistische anormale Bedingung ein: schlechter Sensorwert, späte Rückmeldung, unmöglicher Sollwert, Sequenz-Timeout oder instabiler abgeleiteter Ausgang.

1. Systembeschreibung Definieren Sie die Maschine oder den Prozess, das Steuerungsziel, die wichtigsten E/A und die Rolle jeder KI-beeinflussten Entscheidungslogik.
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die relevante Logik und die entsprechende simulierte Maschinenreaktion zusammen. Code ohne Prozesszustand ist nur die halbe Geschichte.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung Dokumentieren Sie die Logikänderung, Ausgangsbegrenzung, Hinzufügung von Verriegelungen, Korrektur der Zustandsmaschine oder Reduzierung der Scan-Last.
6. Gelernte Lektionen Geben Sie an, was der Test über Determinismus, Prozessverhalten, Fehlerbegrenzung oder Inbetriebnahmerisiken ergeben hat.

Diese Struktur ist wesentlich stärker als „hier ist mein Projekt“. Sie zeigt, dass der Ingenieur Korrektheit definieren, das System absichtlich zum Absturz bringen und es mit Nachweisen verbessern kann. Das kommt der echten Arbeit näher.

Die geltenden Standards und die Literatur befürworten keinen beiläufigen Einsatz von KI in Regelschleifen. Sie weisen auf ein diszipliniertes Lebenszyklusmanagement, eine begrenzte Nutzung und eine starke Validierung hin.

Die relevantesten Anker sind:

• IEC 61131-3 für SPS-Programmiersprachen und Implementierungsstruktur.
• IEC 61508 für den Lebenszyklus funktionaler Sicherheit, systematische Fähigkeiten und Nachweisdisziplin in sicherheitsbezogenen Systemen.
• exida-Leitlinien und Literatur zur Sicherheitspraxis für Softwarequalität, Verifizierungsstrenge und Fehlervermeidung im Kontext der industriellen Automatisierung.
• Literatur zu digitalen Zwillingen und Simulation für virtuelle Inbetriebnahme, cyber-physische Validierung und Lebenszykluseffizienz.
• Literatur zu menschlichen Faktoren und immersivem Training, bei der Ansprüche auf Trainingseffektivität, Verständnis und Probenwert beschränkt sind, anstatt überzogene Ansprüche an die Einsetzbarkeit zu stellen.

Die verantwortungsvolle Schlussfolgerung ist eng gefasst: KI kann bei der Logikübersetzung und dem Inferenzdesign helfen, aber der industrielle Einsatz hängt weiterhin von deterministischer Implementierung, begrenzten Ausgängen, nachvollziehbarer Überprüfung und simulationsgestützter Validierung ab.

- Für einen tieferen Einblick in mathematische Funktionen lesen Sie Konvertierung von Gewichten neuronaler Netze in SPS-Logik: Die Industrie 4.0-Grenze. - Um zu verstehen, wie dies auf autonome Systeme anwendbar ist, siehe Agentische KI in der Automatisierung: Wie sich SPS an unabhängige Entscheidungssysteme anpassen.

• Entdecken Sie unseren vollständigen Lehrplan zur Meisterschaft in fortgeschrittener Kontaktplan-Logik, um die grundlegenden Regeln deterministischer Programmierung zu verstehen.
• Üben Sie das sichere Begrenzen von KI-Ausgängen in einer simulierten Umgebung mit dem Yaga Assistant Sandbox Preset in OLLA Lab.

- IEC 61131-3: Programmierbare Steuerungen — Teil 3: Programmiersprachen - IEC 61508 Übersicht zur funktionalen Sicherheit - NIST AI Risk Management Framework (AI RMF 1.0) - Digital Twin in Manufacturing Review (CIRP Journal) - Industrial AI for Industry 4.0 (Manufacturing Letters)