Wie man neuronale Netzgewichte für die Anomalieerkennung in PLC-Strukturtext konvertiert

Die Konvertierung von Gewichten neuronaler Netze in PLC-Strukturtext bedeutet, die Gewichte und Biases eines trainierten Modells zu exportieren, sie als IEC 61131-3-Arrays neu zu schreiben und die Feedforward-Mathematik deterministisch innerhalb des PLC-Zyklus auszuführen. Das ingenieurtechnische Ziel ist nicht „KI in der Steuerung“ als Werbeslogan, sondern eine begrenzte, testbare Inferenz ohne Abhängigkeit von Edge-Netzwerken.

Neuronale Netze werden nicht allein deshalb industriell nützlich, weil sie Daten in Python gut klassifizieren. Sie werden nützlich, wenn ihr Ausführungspfad für ein Steuerungssystem, das von Zykluszeiten, Watchdog-Grenzen und Fehlerverhalten abhängt, ausreichend vorhersehbar ist.

Für die Hochgeschwindigkeits-Anomalieerkennung kann das Senden von Prozessdaten an einen externen Edge-PC Latenz, Jitter und einen weiteren Fehlerpunkt zwischen Signal und Aktion einführen. Diese Architektur mag für beratende Analytik akzeptabel sein. Sie ist weniger geeignet, wenn der Modellausgang an eine Freigabe, eine Abschaltung oder eine Verriegelung gekoppelt ist. Die OT hat wenig Geduld für elegante Architekturen, die unelegant versagen.

Eine begrenzte Alternative besteht darin, ein leichtgewichtiges trainiertes Modell – typischerweise ein flaches Multi-Layer-Perzeptron – in IEC 61131-3 Strukturtext zu exportieren und die Inferenz direkt im Controller auszuführen.

Ampergon Vallis Metrik: In einer internen OLLA Lab-Simulation fügte ein 3-schichtiges MLP mit einer 16x16 Fließkomma-Matrix in der verborgenen Schicht bei wiederholten Inferenztests 1,2 ms zur simulierten Zyklusausführung hinzu. Methodik: n=25 Simulationsläufe derselben Feedforward-Aufgabe, Basis-Vergleich = identische Logik ohne Matrixausführung, Zeitfenster = eine Validierungssitzung im März 2026. Dies stützt die Aussage, dass kleine neuronale Inferenzblöcke auf deterministische Machbarkeit in einer PLC-ähnlichen Umgebung getestet werden können. Dies beweist nicht die Eignung für jeden Controller, jedes Zyklusbudget oder jede Sicherheitsfunktion.

Die Ausführung der Inferenz innerhalb der PLC entfernt den Netzwerktransport aus dem kritischen Ausführungspfad. Das ist der zentrale ingenieurtechnische Grund.

Ein Edge-PC kann für nicht-kritische Überwachung, Historian-Analytik oder Wartungs-Dashboards ausreichen. Es ist eine andere Sache, wenn der Modellausgang an einer deterministischen Steuerungsentscheidung beteiligt sein muss. Wenn die Netzwerkverbindung abbricht, bricht der Inferenzpfad mit ihr ab. Das Problem ist nicht, dass Edge-Computing falsch ist; das Problem ist, dass Steuerungslogik weniger nachsichtig ist als Analytik-Architektur.

Der Unterschied ist einfach:

• Edge-Inferenz ist typischerweise asynchron, netzwerkabhängig und wird außerhalb des PLC-Zyklus geplant.
• PLC-interne Inferenz ist nur dann deterministisch, wenn Ausführungszeit, Speichernutzung und Fehlerverhalten innerhalb der Controller-Task begrenzt sind.

Für eine Anomalieerkennung, die an eine Motorfreigabe, Ventil-Sperre oder Ablaufsteuerung gekoppelt ist, zählt die deterministische Lokalität. Ein Ergebnis, das zu spät eintrifft, ist funktional oft gleichbedeutend mit gar keinem Ergebnis.

Welcher Standardkontext ist hier relevant?

Funktionale Sicherheitsnormen unterstützen keine beiläufigen Timing-Annahmen. Die IEC 61508 befasst sich mit vorhersehbarem Verhalten, validierter Ausführung und bekannter Fehlerreaktion, nicht damit, ob ein Modell in einem Notebook beeindruckend aussah.

Das erfordert eine sorgfältige Abgrenzung:

• Das Einbetten eines neuronalen Netzes in Strukturtext macht es standardmäßig nicht zu einer Sicherheitsfunktion.
• Es kann deterministische Prozessüberwachungslogik unterstützen, wenn die Ausführung validiert, begrenzt und angemessen separiert ist.
• Wenn der Ausgang sicherheitsrelevante Aktionen beeinflusst, steigt die Beweislast drastisch. „Es hat in der Simulation funktioniert“ ist kein Sicherheitsnachweis.

Ein weit verbreitetes Missverständnis ist, dass KI in der PLC automatisch industrieller wird. Sie kommt lediglich dem Zyklus näher. Der schwierige Teil bleibt der Nachweis.

Nur kleine Feedforward-Modelle sind in den meisten PLC-Kontexten praktikabel. Das ist die nützliche Grenze.

Der häufigste Kandidat ist ein flaches Multi-Layer-Perzeptron (MLP), das offline in MATLAB, Python oder einer ähnlichen Umgebung trainiert und dann als statische Gewichte und Biases exportiert wird. Dies funktioniert, weil die Inferenz für ein festes MLP nur aus Arithmetik besteht:

• Matrixmultiplikation
• Bias-Addition
• Auswertung der Aktivierungsfunktion
• Schwellenwert- oder Klassifizierungslogik

Diese Arithmetik ist mühsam, aber deterministisch.

Die Modelle, die am wahrscheinlichsten passen, sind:

• Single-Hidden-Layer- oder flache MLPs
• Kleine Eingangsvektoren
• Begrenzte Anzahl an Hidden-Nodes
• Einfache Aktivierungsfunktionen, wie ReLU oder begrenzte lineare Approximationen

Die Modelle, die am wenigsten sauber passen, sind:

• Rekurrente Netze
• Große Convolutional-Modelle
• Transformer-Architekturen
• Alles, was dynamisches Speicherverhalten, nicht unterstützte Bibliotheken oder erheblichen Fließkomma-Durchsatz erfordert

Dies ist keine Aussage über KI-Fähigkeiten im Allgemeinen. Es ist eine Aussage über Controller-Wirtschaftlichkeit und Zyklusdisziplin.

Der Konvertierungsprozess ist im Konzept einfach und im Detail unerbittlich. Die meisten Fehler sind nicht mathematischer Natur. Es sind Fehler bei der Indizierung, Skalierung, dem Datentyp oder der Task-Zeit.

### Schritt 1: Trainieren eines leichtgewichtigen Modells offline

Trainieren Sie das Modell in MATLAB, Python oder einer anderen ML-Umgebung unter Verwendung historischer Prozessdaten oder gelabelter Ereignisdaten.

Gute Kandidaten für den PLC-Einsatz haben meist:

• normalisierte numerische Eingänge
• begrenzte Merkmalsanzahl
• stabile Betriebsbereiche
• klare Anomalie-Labels oder Schwellenwertlogik
• einen Inferenzpfad, der erklärt und begrenzt werden kann

Wenn das Modell eine Desktop-GPU benötigt, um flüssig zu laufen, gehört es normalerweise nicht in eine Standard-Controller-Task.

### Schritt 2: Exportieren von Gewichten und Biases

Extrahieren Sie die trainierten Parameter aus dem Modell:

• Eingangs-zu-Hidden-Gewichtsmatrix
• Hidden-Layer-Bias-Vektor
• Hidden-zu-Ausgangs-Gewichtsmatrix
• Ausgangs-Layer-Bias-Vektor

Typische Exportformate sind:

• CSV
• JSON
• MATLAB-Arrays
• Python NumPy-Arrays als Text

Bewahren Sie in diesem Stadium Folgendes auf:

• Array-Dimensionen
• Zeilen-/Spaltenreihenfolge
• Numerische Präzision
• Eingangs-Normalisierungskonstanten
• Ausgangs-Schwellenwerte

Eine überraschende Anzahl von Implementierungsproblemen sind in Wirklichkeit nur transponierte Matrizen.

### Schritt 3: Konvertieren der Parameter in IEC 61131-3-konforme Arrays

Schreiben Sie die Modellparameter als Strukturtext-Arrays unter Verwendung von Controller-unterstützten Datentypen um, typischerweise `REAL` oder `LREAL`, abhängig von der Plattformfähigkeit und dem Zyklusbudget.

Beispiel für die Form-Abbildung:

• `W1[HiddenNodes, InputNodes]`
• `B1[HiddenNodes]`
• `W2[OutputNodes, HiddenNodes]`
• `B2[OutputNodes]`

Definieren Sie außerdem:

• Eingangsvektor-Arrays
• Zwischen-Node-Summen-Arrays
• Aktivierungs-Ausgangs-Arrays
• Finale Inferenz-Ausgangs-Arrays

Die Wahl des Datentyps ist wichtig. `LREAL` kann die numerische Genauigkeit verbessern, aber je nach Controller-Architektur auch die Ausführungskosten erhöhen.

### Schritt 4: Nachbilden des Feedforward-Durchlaufs in Strukturtext

Implementieren Sie das Modell als explizite Arithmetik:

1. Initialisieren Sie jede Node-Summe mit ihrem Bias
2. Akkumulieren Sie die gewichteten Eingangsprodukte
3. Wenden Sie die Aktivierungsfunktion an
4. Leiten Sie die aktivierten Ausgänge an die nächste Schicht weiter
5. Vergleichen Sie den finalen Ausgang mit einem Schwellenwert oder einer Klassifizierungsregel

Hier wird das Modell zu einem deterministischen Arithmetikblock.

### Schritt 5: Nachbilden der Vorverarbeitung und Ausgangslogik

Ein Modell, das auf normalisierten Eingängen trainiert wurde, muss normalisierte Eingänge in der PLC erhalten. Andernfalls ist die Inferenz mathematisch korrekt und operativ falsch.

Sie müssen implementieren:

• Skalierung
• Offset-Korrektur
• Begrenzung (Clamping), falls erforderlich
• Behandlung fehlender Signale
• Ausgangs-Schwellenwertbildung
• Fehlerzustandsverhalten, falls der Inferenzblock ungültige Daten erhält

Ein Modell ohne seinen Vorverarbeitungspfad ist nicht implementiert. Es ist lediglich kopiert.

Matrixmultiplikation in Strukturtext wird üblicherweise mit verschachtelten `FOR`-Schleifen und expliziter Akkumulation in Node-Summen-Arrays implementiert. Das Ziel ist Korrektheit, Determinismus und Sichtbarkeit der Zykluszeit.

Beispiel: Gewichtete Summe der Hidden-Layer

Sprache: Strukturtext

// Gewichtete Summe der Hidden-Layer FOR i := 0 TO HiddenNodes - 1 DO NodeSum[i] := Bias1[i]; FOR j := 0 TO InputNodes - 1 DO NodeSum[i] := NodeSum[i] + (InputArray[j] * Weight1[i, j]); END_FOR; END_FOR;

Dieser Code führt das Skalarprodukt zwischen dem Eingangsvektor und der Gewichtszeile jedes Neurons der Hidden-Layer aus und addiert dann den entsprechenden Bias.

Implementierungsprüfungen, die wichtig sind:

• Bestätigen Sie, ob Ihre PLC nullbasierte oder einsbasierte Array-Konventionen verwendet
• Halten Sie Array-Dimensionen explizit
• Initialisieren Sie Summen vor der Akkumulation
• Vermeiden Sie versteckte Typkonvertierungen
• Testen Sie die Worst-Case-Ausführungszeit, nicht nur die nominale Ausführungszeit

Eine Schleife, die einmal funktioniert, ist eine Demo. Eine Schleife, die bei Task-Rate unter verrauschten Eingängen funktioniert, ist Ingenieurskunst.

Wie berechnet man die Ausgangsschicht?

Die Ausgangsschicht folgt dem gleichen Muster wie die Aktivierungen der Hidden-Layer.

Sprache: Strukturtext

// Gewichtete Summe der Ausgangsschicht FOR i := 0 TO OutputNodes - 1 DO OutputSum[i] := Bias2[i]; FOR j := 0 TO HiddenNodes - 1 DO OutputSum[i] := OutputSum[i] + (HiddenOutput[j] * Weight2[i, j]); END_FOR; END_FOR;

Für einen einzelnen Anomalie-Score können `OutputNodes` gleich `1` sein, wobei der finale Score mit einem Schwellenwert verglichen wird.

ReLU ist eine der einfacheren Aktivierungsfunktionen, da sie stückweise linear ist. In Strukturtext wird sie zu einer einfachen Bedingung.

Sprache: Strukturtext

// ReLU-Aktivierung FOR i := 0 TO HiddenNodes - 1 DO IF NodeSum[i] < 0.0 THEN HiddenOutput[i] := 0.0; ELSE HiddenOutput[i] := NodeSum[i]; END_IF; END_FOR;

Dies bewahrt die grundlegende ReLU-Regel:

• wenn Eingang < 0, Ausgang = 0
• sonst Ausgang = Eingang

Diese Einfachheit ist in PLCs nützlich, da sie teurere nichtlineare Funktionen vermeidet.

Welche anderen Aktivierungsansätze sind praktikabel?

Praktikable Optionen hängen von der Controller-Fähigkeit ab, aber gängige Ansätze umfassen:

- ReLU: am einfachsten für die direkte Implementierung - Lineare Aktivierung: nützlich für Ausgänge im Regressionsstil - Stückweise Approximation: manchmal verwendet, wenn eine glatte nichtlineare Funktion benötigt wird, aber die native mathematische Unterstützung begrenzt ist

Weniger praktikable Optionen in vielen PLCs sind:

• exakte Sigmoid- oder Tanh-Berechnungen unter Verwendung teurer Exponentialfunktionen
• dynamische Aktivierungsschemata, die nicht unterstützte Bibliotheken erfordern
• Architekturen, die vom Laufzeit-Graph-Verhalten abhängen

In der Steuerungstechnik schlägt begrenztes Verhalten oft elegantes, aber nicht testbares Verhalten.

Anomalieerkennung wird operativ erst dann sinnvoll, wenn der Ausgang an eine definierte Steuerungsaktion gekoppelt ist. „Das Modell lieferte 0,83“ ist noch kein ingenieurtechnisches Ergebnis.

Eine nutzbare Implementierung benötigt:

• einen definierten Anomalie-Score
• einen Schwellenwert oder eine Klassifizierungsregel
• eine Entprell- oder Persistenzregel, falls Rauschen erwartet wird
• eine klare Steuerungsreaktion

Zum Beispiel:

- setze `AnomalyDetected := TRUE` - setze `MotorRunPermissive := FALSE`

• wenn Anomalie-Score > Schwellenwert für 500 ms
• setze einen Alarm
• erfordere eine Quittierung durch den Bediener oder die Aufsicht, je nach Philosophie

Diese Logik muss in Steuerungstermen dokumentiert werden, nicht in ML-Termen.

Operative Definition der Anomalieerkennung

In diesem Artikel bedeutet Anomalieerkennung:

> das Lesen eines begrenzten Satzes von Prozesseingängen, das Ausführen eines deterministischen Feedforward-Inferenzblocks innerhalb der PLC-Task, das Vergleichen des resultierenden Scores mit einem definierten Schwellenwert und das Ändern einer Steuerungszustandsvariablen wie einer Freigabe, eines Alarms oder einer Ablaufsteuerung, wenn die Schwellenwertbedingung erfüllt ist.

Diese Definition ist absichtlich eng gefasst. Sie ist beobachtbar, testbar und für die Validierung geeignet.

Die Hauptrisiken sind Zykluszeitüberschreitung, numerische Diskrepanzen und falsches Vertrauen.

1. Risiko von Zykluszeit und Watchdog

Matrixarithmetik verbraucht Task-Zeit. Wenn der Inferenzblock zu groß oder schlecht strukturiert ist, kann dies Watchdog-Fehler auslösen oder die Reaktionsfähigkeit der Steuerung verschlechtern.

Risikofaktoren sind:

• große Matrizen
• häufige Ausführung in schnellen Tasks
• starke Nutzung von Fließkommazahlen
• wiederholte Normalisierung und Skalierung innerhalb desselben Zyklus
• unnötige Neuberechnungen

Gegenmaßnahmen sind:

• Reduzierung der Modellgröße
• Verschieben der Inferenz in eine langsamere periodische Task, wo angemessen
• Vorberechnung von Konstanten
• Verwendung von Tests mit begrenzter Ausführung
• Validierung des Worst-Case-Einflusses auf die Zykluszeit vor der Implementierung

2. Diskrepanz bei Datentyp und Präzision

Ein Modell, das in `float64` trainiert und in `REAL` implementiert wurde, kann sich an Schwellenwerten anders verhalten. Dieser Unterschied kann numerisch klein und operativ groß sein.

Prüfen Sie:

• numerischen Bereich
• Konsistenz der Skalierung
• Empfindlichkeit des Schwellenwerts
• controller-spezifisches Fließkommaverhalten

3. Fehler bei Indizierung und Matrixorientierung

Eine transponierte Matrix, ein verschobener Index oder eine falsche Bias-Zuordnung können Ausgänge erzeugen, die plausibel aussehen, aber völlig falsch sind.

Deshalb ist deterministische Validierung wichtig. Arithmetische Fehler sind oft höflich genug, um zu kompilieren.

4. Verhalten bei ungültigen Eingängen

Ein fehlender Sensor, ein veralteter Wert, ein gesättigter Messumformer oder eine schlechte analoge Skalierung können die Inferenz korrumpieren.

Definieren Sie:

• was bei schlechter Signalqualität passiert
• ob sich der Block selbst sperrt
• ob der Ausgang sicherheitsgerichtet abschaltet, neutral bleibt oder nur alarmiert
• ob das Ergebnis während Wartungs- oder Anlaufzuständen ignoriert wird

5. Missbrauch in Sicherheitskontexten

Ein Inferenzblock für neuronale Netze sollte nicht als sicherheitsgerichtet bezeichnet werden, nur weil er sich in einer PLC befindet. Wenn er eine sicherheitsrelevante Funktion beeinflusst, werden die Verpflichtungen für Design, Verifizierung und Lebenszyklus wesentlich anspruchsvoller.

OLLA Lab ist hier als begrenzte Validierungsumgebung für risikoreiche Inbetriebnahmeaufgaben nützlich. Es ist keine Abkürzung für Controller-Tests und kein Ersatz für die Abnahme vor Ort. Es ist der Ort, an dem Sie die Fehlerzustände proben, bevor Hardware- und Prozesszeit teuer werden.

In diesem Anwendungsfall kann OLLA Lab Ingenieure unterstützen durch:

• eine browserbasierte Logikumgebung zum Erstellen und Überprüfen von Steuerungslogik
• Simulationsmodus zum Ausführen, Stoppen und Beobachten von Verhalten ohne physische Hardware
• Variablen- und E/A-Sichtbarkeit zur Verfolgung von Zwischenwerten
• realistische szenariobasierte Tests gegen simuliertes Anlagenverhalten
• Validierungs-Workflows im Stil eines digitalen Zwillings, bei denen Logik mit der erwarteten Maschinenreaktion verglichen werden kann

Für den Workflow dieses Artikels ist der praktische Wert klar:

• Schreiben der Inferenzlogik
• Binden von Eingängen an simulierte Prozessvariablen
• Injizieren von Störungen oder anormalen Bedingungen
• Beobachten von Ausgangszustandsänderungen
• Prüfen, ob die Steuerungsreaktion der beabsichtigten Philosophie entspricht

Das ist es, was Simulation-Ready operativ bedeuten sollte: ein Ingenieur, der Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor sie einen Live-Prozess erreicht.

Was bedeutet Validierung durch digitalen Zwilling hier?

In diesem begrenzten Kontext bedeutet Validierung durch digitalen Zwilling, Steuerungslogik gegen ein realistisches simuliertes Anlagenmodell zu testen, sodass der Ingenieur vergleichen kann:

• Zustand in Kontaktplan oder Strukturtext
• E/A-Zustand
• Prozessreaktion
• Umgang mit anormalen Bedingungen
• resultierende Steuerungsaktion

Es bedeutet nicht, dass das simulierte Modell automatisch eine perfekte Nachbildung des Verhaltens vor Ort ist. Es bedeutet, dass die Logik vor der Implementierung im Feld gegen repräsentative Maschinen- oder Prozessdynamiken geprobt werden kann.

Ein praktischer Workflow besteht darin, das neuronale Netz als einen Block innerhalb eines größeren Steuerungsnarrativs zu behandeln, anstatt als Neuheitsobjekt.

Eine repräsentative Validierungssequenz wäre:

1. Erstellen des Inferenzblocks Implementieren Sie die exportierten Gewichte, Biases, Normalisierung und Schwellenwertlogik in Strukturtext oder einem äquivalenten unterstützten Steuerungslogik-Workflow.
2. Binden der Eingänge an simulierte Prozesssignale Mappen Sie die Modelleingänge auf Variablen wie Vibration, Motorstrom, Temperaturanstieg, Druckschwankung oder Durchflussinstabilität.
3. Definieren des erwarteten Normalzustands Bestätigen Sie, dass der Modellausgang während des gesunden Betriebs unter dem Schwellenwert bleibt.
4. Injizieren einer anormalen Bedingung Führen Sie eine Störung ein, wie z. B. oszillierende Vibration, Sensor-Spikes, Drift oder instabiles Lastverhalten.
5. Beobachten des Inferenz-Ausgangs und der Steuerungsreaktion Verifizieren Sie, dass der Anomalie-Score den Schwellenwert nur dann überschreitet, wenn dies beabsichtigt ist, und dass sich die Freigabe, der Alarm oder der Sequenzzustand korrekt ändern.
6. Messen der Logiklast Überprüfen Sie, ob die hinzugefügte Arithmetik inakzeptable Ausführungskosten oder instabiles Verhalten erzeugt.

Diese Sequenz ist wichtig, weil Anomalieerkennung nur nützlich ist, wenn sie an Prozesskonsequenzen gekoppelt ist. Ein Score ohne Aktionspfad ist nur eine Zahl.

Eine Screenshot-Galerie ist ein schwacher Nachweis. Ein kompakter Validierungsbericht ist für Prüfer, Ausbilder und Arbeitgeber nützlicher, da er das logische Vorgehen zeigt, nicht nur die Vertrautheit mit der Oberfläche.

Verwenden Sie diese Struktur:

1. Systembeschreibung Beschreiben Sie die Anlage, das Prozessziel, relevante Eingänge und wo der Anomalieerkennungsblock in der Steuerungsphilosophie sitzt.
2. Operative Definition des korrekten Verhaltens Geben Sie genau an, was die Logik unter normalen und anormalen Bedingungen tun muss, einschließlich Schwellenwerten, Timing und erwarteten Ausgangszuständen.
3. Logik- und simulierter Anlagenzustand Zeigen Sie die implementierte Logik und das entsprechende simulierte Maschinen- oder Prozessverhalten während des Tests.
4. Der injizierte Fehlerfall Dokumentieren Sie die eingeführte Störung, wie z. B. Sensorrauschen, Drift, Oszillation oder anormale Last.
5. Die vorgenommene Revision Notieren Sie, was sich nach dem ersten Test geändert hat – Schwellenwertanpassung, Entprelllogik, Skalierungskorrektur, Task-Platzierung oder Matrixoptimierung.
6. Gelernte Lektionen Fassen Sie zusammen, was der Test über Implementierbarkeit, Fehlalarme, Zykluslast oder Steuerungsphilosophie ergeben hat.

Dieser Nachweis ist dem Urteilsvermögen bei der Inbetriebnahme viel näher als ein polierter Screenshot.

Die Implementierung sollte durch begrenzte Verifizierung gesteuert werden, nicht durch Enthusiasmus.

Verwenden Sie eine Checkliste vor der Implementierung:

• Modellgröße ist angemessen für den Controller und die Task-Rate
• Eingangsskalierung entspricht den Trainingsbedingungen
• Gewichte und Biases sind korrekt gemappt
• Aktivierungslogik ist exakt wie beabsichtigt implementiert
• Schwellenwertverhalten ist dokumentiert
• Umgang mit fehlerhaften Eingängen ist definiert
• Worst-Case-Ausführungszeit ist getestet
• Steuerungsreaktion auf Anomalie ist verifiziert
• Fallback-Verhalten ist definiert, falls der Inferenzblock ungültig ist
• Standortspezifische Inbetriebnahmetests sind geplant

Wenn das Modell diese Checkliste nicht übersteht, ist es nicht bereit für die PLC. Es kann an anderer Stelle immer noch nützlich sein.

Dieser Ansatz löst ein spezifisches OT-Problem: wie man ein kleines trainiertes Modell deterministisch innerhalb einer PLC-ähnlichen Steuerungsumgebung ausführt, ohne sich auf eine externe Inferenzinfrastruktur zu verlassen.

Er kann helfen bei:

• Anomalie-Scoring mit niedriger Latenz
• begrenzter lokaler Inferenz
• Reduzierung der Netzwerkabhängigkeit bei Steuerungsentscheidungen
• Validierung der Modellarithmetik gegen realistisches Prozessverhalten

Er löst nicht:

• Sicherheitszertifizierung durch Implikation
• Modell-Governance an sich
• Anlagenspezifische Inbetriebnahme allein durch Simulation
• Eignung großer oder komplexer neuronaler Architekturen für Standard-PLC-Hardware

Diese Grenze sollte sauber gehalten werden.

Die Konvertierung von Gewichten neuronaler Netze in PLC-Strukturtext ist technisch machbar, wenn das Modell klein ist, der arithmetische Pfad explizit ist und die Ausführungslast gegen Controller-Beschränkungen validiert wurde. Der Punkt ist nicht, dass PLCs Python-Umgebungen imitieren sollen. Der Punkt ist, eine begrenzte Inferenzfunktion dort zu platzieren, wo deterministische Reaktion am wichtigsten ist.

Die ingenieurtechnische Sequenz ist klar:

• offline trainieren
• Gewichte und Biases exportieren
• als IEC 61131-3-Arrays umschreiben
• Feedforward-Mathematik und Aktivierungslogik implementieren
• Zykluszeit-Einfluss und Fehlerverhalten validieren
• Steuerungsfolgen gegen realistische simulierte Prozessbedingungen testen

Hier wird OLLA Lab operativ nützlich. Es bietet einen Ort, um matrixlastige Logik zu proben, E/A- und Variablenverhalten zu beobachten, anormale Bedingungen zu injizieren und das Design vor der Live-Inbetriebnahme zu härten. Das ist ein glaubwürdiger Einsatz von Simulation: nicht um den Feldnachweis zu ersetzen, sondern um den Feldnachweis weniger leichtsinnig zu machen.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 Functional safety overview - NIST AI Risk Management Framework (AI RMF 1.0) - Digital twin review (IFAC-PapersOnLine) - Industrial AI in Industry 4.0 (Manufacturing Letters)