So erstellen Sie KI-Prompts für die SPS-Programmierung mit Steuerungsphilosophien für Yaga

Effektives KI-Prompting für die SPS-Programmierung erfordert strukturierte Steuerungsphilosophien, keine vagen Anfragen. Wenn Ingenieure explizite E/A-Mappings, Freigaben, Verriegelungen, Sequenzzustände und Fehlerbedingungen bereitstellen, kann Yaga Kontaktplan-Gerüste generieren, die in der Simulationsumgebung des OLLA Lab wesentlich einfacher zu validieren sind.

KI scheitert bei SPS-Aufgaben nicht, weil sie „schlecht im Programmieren“ ist. Sie scheitert, weil Kontaktplan-Logik nicht nur aus Code-Generierung besteht; es handelt sich um deterministisches Steuerungsverhalten unter Berücksichtigung von Randbedingungen, Scan-Reihenfolge und abnormalen Zuständen. Dieser Unterschied wird oft übersehen.

Während einer internen Beta-Übung des Yaga Assistant im OLLA Lab erzeugten Prompts, die ein Tag-Verzeichnis, einen definierten sicheren Zustand und mindestens eine explizite Verriegelung enthielten, in 22 von 24 Fällen (91,7 %) simulationsfähige Gerüste im ersten Durchlauf. Im Gegensatz dazu erforderten generische Prompts wie „Schreibe eine Pumpensequenz“ in 17 von 24 Fällen (70,8 %) erhebliche Korrekturen, bevor eine Simulation möglich war. Methodik: n=48 Prompt-Aufgaben-Durchläufe für Pumpen-, Mischer-, Förderband- und Tankfüllstandsübungen; Basisvergleich = generischer natürlichsprachlicher Prompt versus strukturierter Steuerungsphilosophie-Prompt; Zeitfenster = internes Beta-Fenster, Februar–März 2026. Dies stützt eine eng gefasste Behauptung: Die Prompt-Struktur beeinflusst die Nutzbarkeit im ersten Durchlauf in der Simulation maßgeblich. Es beweist nicht die Einsatzfähigkeit vor Ort, die Sicherheit oder die Produktionsreife.

In der Automatisierung sollte Prompt Engineering eng definiert werden: als systematische Übersetzung von mechanischen Randbedingungen, E/A-Mapping und Sicherheitsverriegelungen in maschinenlesbare Parameter, damit ein KI-Agent syntaktisch korrekte, testbare Gerüste generieren kann. Das ist ein nützliches Werkzeug, kein Ersatz für technisches Urteilsvermögen. Das OLLA Lab ist hierbei als Validierungsschleife relevant, nicht als Freibrief.

Allgemeine LLMs scheitern an Kontaktplan-Logik, weil sie plausible Token-Sequenzen vorhersagen, während SPSen deterministische Scan-Logik gegen zustandsbehaftete Ein- und Ausgänge ausführen. Ein Sprachmodell sieht Textkontinuität; eine Steuerung sieht Auswertungsreihenfolge, Speicherbits, Flankenbedingungen und Gerätezustände.

Kontaktplan-Logik ist zudem räumlich. Parallele Zweige, Selbsthaltungen, Freigabeketten und sich gegenseitig ausschließende Zustände vermitteln Bedeutung durch Struktur, nicht nur durch Worte. Ein Allzweck-LLM neigt dazu, diese Struktur in Text zu linearisieren und kann dabei die Ausführungsabsicht verlieren. Dies ist ein Grund, warum KI-generierter Kontaktplan kompetent aussehen kann, sich aber fehlerhaft verhält.

Ein zweiter Fehlermodus ist ein schwaches Bewusstsein für den Scan-Zyklus. SPS-Logik wird wiederholt ausgewertet, und Ausgänge können je nach Programmstruktur innerhalb desselben Scans geschrieben, zurückgesetzt oder überschrieben werden. Ohne explizite Einschränkungen kann ein LLM Folgendes generieren:

• doppelte Schreibzugriffe auf dieselbe Ausgangsspule,
• fehlendes Flankenverhalten (One-Shot),
• Race Conditions zwischen Automatik- und Handbetrieb,
• Timer mit unklaren Rücksetzbedingungen,
• analoge Schwellenwerte ohne Hysterese oder Fehlerbehandlung,
• Verriegelungen, die in Kommentaren erscheinen, aber nicht in der ausführbaren Logik.

Das häufige Ergebnis ist Praktikern bekannt: Logik, die sich gut liest, aber bei Änderung der Eingänge sofort fehlerhaft reagiert. Syntax ist billig; Determinismus ist schwieriger.

Diese Einschränkung steht im Einklang mit der Literatur zu LLM-Reasoning und Code-Zuverlässigkeit. Veröffentlichte Arbeiten zu Software und eingebetteten Systemen legen nahe, dass die Ausgabequalität abnimmt, wenn Aufgaben eine persistente Zustandsverfolgung, räumliches Denken oder exakte Einhaltung von Randbedingungen erfordern, anstatt flüssige Mustervervollständigung (Bubeck et al., 2023; Huang & Chang, 2023). Die SPS-Programmierung ist in allen drei Punkten besonders unnachgiebig.

Ein automatisierungsgerechter KI-Prompt ist eine kompakte funktionale Spezifikation. Er sollte dem Modell mitteilen, was die Maschine ist, was „sicher“ bedeutet, welche Geräte existieren, welche Bedingungen erfüllt sein müssen, bevor eine Aktion erlaubt ist, und wie mit Fehlern umgegangen werden soll. Wenn der Prompt keine grundlegende Überprüfung der funktionalen Spezifikation (FDS) unterstützt, ist er wahrscheinlich zu vage für eine zuverlässige Kontaktplan-Generierung.

In der Praxis verhält sich ein guter SPS-Prompt weniger wie eine Suchanfrage und mehr wie eine Anweisung an einen Junior-Automatisierungsingenieur. Erfahrene Ingenieure sagen nicht: „Erstelle mir ein Pumpenprogramm.“ Sie spezifizieren den Prozess, die Tags, die Sequenz, die Abschaltungen und den erwarteten Rückfallzustand.

Die 3 Säulen eines Automatisierungs-Prompts

#### 1. Kontext und Zielsetzung

Geben Sie die Maschine oder Prozesseinheit, das Betriebsziel und den sicheren Zustand an.

Beinhaltet:

• Gerätetyp,
• Betriebsmodus,
• Start-/Stopp-Ziel,
• Bedingung für sicheres Abschalten,
• Erwartung bei abnormalem Zustand.

Beispiel:

• „Einzelne Transferpumpe füllt einen Tagestank.“
• „Sicherer Zustand ist Pumpe aus und Auslassventil geschlossen.“
• „Wenn der Füllstandstransmitter ungültig ist, Automatikstart sperren.“

#### 2. E/A- und Tag-Verzeichnis

Definieren Sie die Tags explizit. Die KI arbeitet besser, wenn die Benennung eindeutig und typisiert ist.

Beinhaltet:

• Digitale Eingänge,
• Digitale Ausgänge,
• Analoge Eingänge,
• Analoge Ausgänge (falls relevant),
• Interne Speicherbits,
• Timer und Zähler,
• Alarm- oder Fehlerbits.

Beispiel:

• `DI_PB_Start`
• `DI_PB_Stop`
• `DI_EStop_OK`
• `AI_Tank_Level_Pct`
• `DO_Pump_Run`
• `M_Auto_Mode`
• `T_FillTimeout`

Disziplin bei der Benennung ist nicht kosmetisch. Sie ist der Unterschied zwischen nachvollziehbarer Logik und einem hohen Debugging-Aufwand.

#### 3. Freigaben und Verriegelungen

Definieren Sie, was wahr sein muss, bevor eine Aktion erfolgen kann, und was eine Aktion stoppen muss.

Beinhaltet:

• Freigaben,
• Abschaltungen (Trips),
• Modus-Einschränkungen,
• Rückmeldeanforderungen,
• Timeout-Verhalten,
• Alarmbedingungen.

Beispiel:

• Pumpe darf nur starten, wenn `DI_EStop_OK = TRUE`
• Pumpe darf nur starten, wenn `AI_Tank_Level_Pct < 80`
• Pumpe muss stoppen, wenn `AI_Tank_Level_Pct >= 95`
• Alarm auslösen, wenn Laufbefehl aktiv ist und keine Rückmeldung innerhalb von 3 Sekunden erfolgt

Hier scheitern viele Prompts. Ingenieure spezifizieren oft den Idealfall und lassen die Gründe weg, warum die Maschine den Betrieb verweigern muss. Echte Anlagen verbringen viel Zeit in nicht-normalen Zuständen.

Für KI-Prompts sollte eine Steuerungsphilosophie als die minimale funktionale Spezifikation definiert werden, die zur Generierung testbarer Steuerungsgerüste erforderlich ist. Es ist kein Marketingbegriff und keine vage Design-Erzählung. Operativ sollte sie dieselben Kernverhaltensweisen enthalten, die ein Automatisierungsingenieur in einem FDS-Dokument erwartet:

• Anfangszustand,
• Betriebsmodi,
• Operationssequenz,
• Freigaben,
• Verriegelungen,
• Alarme und Abschaltungen,
• Fehlerreaktionen,
• Rücksetzverhalten,
• Bedieneraktionen,
• Erfolgskriterien.

Diese Definition ist durch technische Beobachtbarkeiten begrenzt. Wenn der Prompt dem Modell nicht mitteilt, was der Prozess tun soll, wenn ein Sensor ausfällt, ein Deckel sich öffnet, ein Füllstand einen Schwellenwert überschreitet oder eine Rückmeldung ausbleibt, dann ist der Prompt keine Steuerungsphilosophie.

Diese Einrahmung entspricht der etablierten industriellen Dokumentationspraxis. IEC 61131-3 regelt SPS-Programmiersprachen, aber gute Kontaktplan-Logik hängt dennoch von der funktionalen Klarheit im Vorfeld ab. Standards retten keine vagen Absichten.

Ein nützliches Missverständnis, das ausgeräumt werden sollte

Prompt Engineering in der Automatisierung geht nicht darum, die KI kreativer zu machen. Es geht darum, die Spezifikation weniger mehrdeutig zu machen.

Der effektivste Weg, Yaga zu prompten, ist die Bereitstellung einer eingeschränkten, wiederverwendbaren Vorlage. Dem Modell sollten die Rolle, das Prozessziel, die Tags, die Sequenz, die Freigaben, die Verriegelungen und das erwartete Ausgabeformat mitgeteilt werden. Wenn einer dieser Punkte implizit bleibt, könnte das Modell improvisieren.

Empfohlene Prompt-Vorlage für Yaga

Agieren Sie als IEC 61131-3 Kontaktplan-Assistent.

Ziel: Erstellen Sie ein Kontaktplan-Gerüst für die folgende Steuerungsaufgabe.

Systembeschreibung: - Ausrüstung: [Maschine/Prozesseinheit] - Betriebsziel: [Was das System tun soll] - Sicherer Zustand: [Welche Ausgänge/Zustände müssen bei Stopp oder Fehler wahr sein]

E/A- und Tag-Verzeichnis: Digitale Eingänge: - [Tag]: [Beschreibung] - [Tag]: [Beschreibung]

Digitale Ausgänge: - [Tag]: [Beschreibung]

Analoge Eingänge: - [Tag]: [Beschreibung und technische Einheiten]

Interne Bits / Timer / Zähler: - [Tag]: [Zweck]

Betriebsmodi:

• [Auto / Hand / Wartung]
• [Modus-Regeln]

Operationssequenz:

Freigaben:

• [Bedingung erforderlich vor Start]
• [Bedingung erforderlich vor Übergang]

Verriegelungen / Abschaltungen:

• [Bedingung, die den Betrieb stoppen oder sperren muss]
• [Fehlerbedingung und Reaktion]

Alarme:

• [Alarmbedingung]
• [Timeout-Bedingung]

Rücksetz- / Wiederherstellungsregeln:

• [Anforderung für manuelles Rücksetzen]
• [Regel für automatisches Rücksetzen, falls erlaubt]

Ausgabeanforderungen:

• Verwenden Sie eine klare Kontaktplan-Struktur (Sprosse für Sprosse)
• Schreiben Sie nicht auf dieselbe Ausgangsspule an mehreren widersprüchlichen Stellen
• Verwenden Sie bei Bedarf benannte interne Bits für Sequenzzustände
• Fügen Sie Kommentare für jede Sprosse hinzu
• Identifizieren Sie Annahmen explizit

Diese Vorlage garantiert keine korrekte Logik. Sie tut etwas Nützlicheres: Sie macht Fehler früher sichtbar.

1. [Schritt 1]
2. [Schritt 2]
3. [Schritt 3]

Junior-Prompt vs. Senior-Prompt

| Prompt-Stil | Beispiel | Wahrscheinliches Ergebnis | |---|---|---| | Junior-Prompt | „Erstelle ein Kontaktplan-Diagramm, das einen Mischer für 10 Sekunden einschaltet, wenn ich Start drücke.“ | Mehrdeutiges Stopp-Verhalten, fehlende Deckel-Verriegelung, unklare Rücksetzlogik, schwache Tag-Struktur | | Senior-Prompt | „Agieren Sie als IEC 61131-3 Programmierer. Erstellen Sie ein Kontaktplan-Gerüst für einen Mischer. Eingänge: `PB_Start` (NO), `PB_Stop` (NC), `LS_LidClosed`, `EStop_OK`. Ausgang: `MTR_Mixer`. Verriegelung: Mischer darf nur laufen, wenn Deckel geschlossen und E-Stop in Ordnung. Verwenden Sie TON für 10s Laufzyklus. Stopp sofort bei Deckelöffnung oder Stopp-Befehl. Sicherer Zustand = Motor aus. Geben Sie Sprossenkommentare an und identifizieren Sie Annahmen.“ | Testbare Basis mit expliziten Freigaben, sichereres Stopp-Verhalten, klarerer Simulationspfad |

Der Unterschied liegt nicht in der Eloquenz. Er liegt in der Dichte der Randbedingungen.

Ein guter SPS-Prompt sollte die Maschine als zustandsbehaftetes System definieren, nicht als verbale Aufgabe. Bevor Yaga eine Sprosse schreibt, sollte der Prompt bereits sechs technische Fragen beantworten.

1. Was ist das System?

Definieren Sie die Ausrüstung, die Prozessgrenze und den beabsichtigten Betrieb.

Beispiel:

• „Duplex-Pumpstation (Lead/Lag) mit Hochalarm und Alternierung.“

2. Was ist „korrektes“ Verhalten?

Definieren Sie das operative Erfolgsziel in beobachtbaren Begriffen.

Beispiel:

• „Im Automatikmodus startet die Lead-Pumpe bei 70 % Füllstand und stoppt bei 30 %; die Lag-Pumpe startet bei 90 %; beide stoppen bei E-Stop oder Motorschutz-Auslösung.“

Dies ist wichtig, da „simulationsbereit“ operativ definiert werden sollte: Ein Ingenieur ist simulationsbereit, wenn er die Steuerungslogik vor Erreichen eines Live-Prozesses gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann. Das ist ein höherer Standard als das Beherrschen der Kontaktplan-Syntax.

3. Was sind die Tags und Signaltypen?

Listen Sie die Tags, Signalrichtung und Einheiten auf.

Beispiel:

• `AI_WetWell_Level_Pct` = Analoger Eingang, Prozent
• `DI_P1_OL_Trip` = Digitaler Eingang, Motorschutz-Auslösung
• `DO_P1_RunCmd` = Digitaler Ausgang

4. Welche abnormalen Zustände existieren?

Definieren Sie Fehler, ungültige Zustände und Fehlerreaktionen.

Beispiel:

• Füllstandstransmitter mit schlechter Qualität,
• Lauf-Rückmeldung fehlt nach Befehl,
• beide Motorschutzschalter aktiv,
• E-Stop nicht in Ordnung,
• HOA-Schalter-Konflikt.

5. Was darf niemals passieren?

Geben Sie verbotenes Verhalten explizit an.

Beispiel:

• „Befehle niemals beide Pumpen gleichzeitig in der manuellen Alternierungslogik.“
• „Kein automatischer Neustart nach Motorschutz-Rücksetzung ohne Bedieneraktion.“
• „Mischer nicht bei offenem Deckel starten.“

6. Welche Annahmen sind erlaubt?

Verlangen Sie von der KI, Annahmen zu deklarieren, anstatt sie zu verbergen.

Beispiel:

• „Nehmen Sie an, dass der Stopp-Taster ein gesunder NC-Kontakt ist, sofern nicht anders angegeben.“
• „Nehmen Sie an, dass die analoge Skalierung bereits vorgelagert durchgeführt wurde.“

Versteckte Annahmen sind eine häufige Quelle für schwache, KI-generierte Kontaktplan-Logik.

Das OLLA Lab validiert KI-generierte Logik, indem es sie in eine Simulationsumgebung einbettet, in der Eingänge, Ausgänge, Variablen und das Geräteverhalten beobachtet und manipuliert werden können, bevor ein Live-Einsatz in Betracht gezogen wird. Das macht es zu einer risikokontrollierten Validierungsschleife, nicht zu einem Orakel.

Der Kontaktplan-Editor bietet die Logik-Oberfläche. Der Simulationsmodus bietet die Ausführung. Das Variablen-Panel bietet Beobachtbarkeit für Tags, E/A-Zustände, Analogwerte und Steuerungsvariablen. Zusammen ermöglichen sie es einem Ingenieur zu testen, ob sich die generierte Logik wie spezifiziert verhält, wenn sich die Bedingungen ändern.

In der Praxis bedeutet dies, dass Sie:

• digitale Eingänge umschalten,
• Fehlerbedingungen erzwingen,
• die Ausgangsreaktion prüfen,
• Timer und interne Bits beim Zustandswechsel beobachten,
• den Kontaktplan-Zustand gegen das simulierte Geräteverhalten vergleichen,
• die Logik nach einem fehlgeschlagenen Test überarbeiten können.

Validierung ist kein Screenshot einer korrekt aussehenden Sprosse. Validierung ist eine Abfolge von widerlegten Annahmen, gefolgt von einer präziseren Logik.

Wie die Generieren-Validieren-Schleife aussieht

1. Gerüst mit Yaga generieren Verwenden Sie einen strukturierten Steuerungsphilosophie-Prompt.
2. Den generierten Kontaktplan prüfen Überprüfen Sie Tag-Namen, Ausgangszuordnungen, Sequenzstruktur und die Platzierung von Verriegelungen.
3. Die Logik in der Simulation ausführen Beginnen Sie mit nominalen Bedingungen.
4. Abnormale Bedingungen injizieren Erzwingen Sie Sensorausfall, ungültige Freigaben, offene Deckelzustände, Motorschutz-Auslösungen oder Timeout-Fälle.
5. Beobachten, ob die Logik sicher fehlschlägt Bestätigen Sie sicheres Stoppen, Alarm-Speicherung, Neustartsperre oder das Halten des Zustands wie erforderlich.
6. Überarbeiten und erneut testen Verschärfen Sie den Prompt oder bearbeiten Sie den Kontaktplan direkt.

Hier wird das OLLA Lab operativ nützlich. Es gibt Ingenieuren einen Ort, um risikoreiche Aufgaben zu üben, für die Live-Systeme schlechte Lehrmeister sind.

Sie testen dies, indem Sie Fehlerfälle definieren, bevor Sie der nominalen Sequenz vertrauen. Eine Kontaktplan-Routine, die nur funktioniert, wenn jedes Signal sich korrekt verhält, ist nicht validiert; sie ist lediglich ungeprüft.

Testen Sie in der Simulation mindestens diese Kategorien.

Eingangs-Integritätsfehler

• Sensor klemmt auf High,
• Sensor klemmt auf Low,
• Transmitter außerhalb des Bereichs,
• schlechter Analogwert,
• Rückmeldung fehlt nach Befehl.

Verriegelungsfehler

• E-Stop nicht in Ordnung,
• Schutzgitter oder Deckel offen,
• Freigabe während des Laufs verloren,
• Motorschutz-Auslösung aktiv,
• Ventil-Rückmeldung nicht erreicht.

Sequenzfehler

• Timer setzt nie zurück,
• Zustandsbit bleibt gesetzt,
• Hand- und Automatikbefehl überschneiden sich,
• Neustart erfolgt nach Auslösung ohne Rücksetzung,
• Ausgang bleibt nach Stopp-Pfad bestromt.

Analog- und PID-bezogene Fehler

• Prozessvariable überschreitet Abschalt-Schwellenwert,
• analoge Hysterese fehlt,
• Alarm-Flattern nahe dem Schwellenwert,
• Reglerausgang sättigt,
• Modus-Übergang verursacht Sprung.

Das Vorhandensein von Analog-Tools und PID-Dashboards im OLLA Lab ist hier wichtig, da viele KI-Beispiele in diskreter Logik gefangen bleiben. Echte Prozesssteuerung ist das meist nicht. Eine Pumpstation, RLT-Anlage, thermischer Regelkreis oder Dosieranlage umfasst oft Schwellenwerte, Verzögerungen, Hysteresen und modusabhängiges Verhalten.

Ein ausgearbeitetes Beispiel sollte die Übersetzung von der Prozessabsicht in maschinenlesbare Randbedingungen zeigen. Unten ist ein kompaktes Mischer-Beispiel, das für Yaga geeignet ist.

Beispiel für einen strukturierten Prompt

Agieren Sie als IEC 61131-3 Kontaktplan-Assistent.

Systembeschreibung: - Ausrüstung: Chargenmischer - Betriebsziel: Mischer nach Bediener-Startbefehl für 10 Sekunden laufen lassen - Sicherer Zustand: Mischer-Motor sofort aus bei Stopp, E-Stop-Verlust oder Deckel offen

E/A- und Tag-Verzeichnis: Digitale Eingänge: - DI_PB_Start: Start-Taster, Schließer - DI_PB_Stop: Stopp-Taster, Öffner - DI_Lid_Closed: Deckel-geschlossen-Rückmeldung - DI_EStop_OK: Not-Aus in Ordnung

Digitale Ausgänge: - DO_Mixer_Run: Mischer-Motor-Laufbefehl

Interne Bits / Timer: - M_Mix_Cycle_Active: Mix-Zyklus-Speicher - T_Mix_Run: 10 Sekunden TON-Timer

Operationssequenz:

Freigaben:

• DI_Lid_Closed = TRUE
• DI_EStop_OK = TRUE
• DI_PB_Stop in Ordnung

Verriegelungen / Abschaltungen:

• Wenn Deckel während des Laufs öffnet, DO_Mixer_Run sofort stromlos schalten
• Wenn E-Stop nicht in Ordnung, DO_Mixer_Run sofort stromlos schalten

Ausgabeanforderungen:

• Kontaktplan-Gerüst Sprosse für Sprosse bereitstellen
• Verwenden Sie einen eindeutigen Ausgangspfad für DO_Mixer_Run
• Fügen Sie Sprossenkommentare hinzu
• Geben Sie alle Annahmen an

1. Bei Startbefehl Mix-Zyklus nur beginnen, wenn Deckel geschlossen und E-Stop in Ordnung
2. Mischer-Motor für 10 Sekunden laufen lassen
3. Motor stoppen, wenn Timer abgelaufen
4. Sofort abbrechen bei Stopp-Befehl, Deckel offen oder E-Stop nicht in Ordnung

Was nach der Generierung zu prüfen ist

Nachdem Yaga den Kontaktplan generiert hat, prüfen Sie auf:

• einen klaren Pfad für `DO_Mixer_Run`,
• Timer-Freigabe an den aktiven Zykluszustand gebunden,
• sofortiges Abfallen bei Deckelöffnung oder E-Stop-Verlust,
• kein versteckter automatischer Neustart,
• Kommentare, die dem tatsächlichen Sprossenverhalten entsprechen,
• explizite Annahmen.

Führen Sie es dann in der Simulation aus und erzwingen Sie `DI_Lid_Closed` auf „falsch“ während des zeitgesteuerten Laufs. Wenn der Motorbefehl bestehen bleibt, ist der Prompt oder die Logik falsch.

Ingenieure sollten KI-unterstützte SPS-Arbeit als technischen Nachweis dokumentieren, nicht als Galerie von Interface-Screenshots. Ein glaubwürdiger Datensatz zeigt, was das System tun sollte, wie es getestet wurde, wie es fehlschlug und wie es korrigiert wurde.

Verwenden Sie diese Struktur:

Protokollieren Sie den exakt eingeführten Fehler: Sensorausfall, Motorschutz, Freigabeverlust, Timeout, ungültiger Analogwert usw.

1. Systembeschreibung Definieren Sie die Ausrüstung, das Prozessziel, den Betriebsmodus und den sicheren Zustand.
2. Operative Definition von „korrekt“ Geben Sie die beobachtbaren Erfolgskriterien an, einschließlich Stopp-Bedingungen und Verhalten bei abnormalem Zustand.
3. Kontaktplan-Logik und simulierter Gerätezustand Zeigen Sie den generierten oder bearbeiteten Kontaktplan neben dem relevanten simulierten Maschinenzustand oder Variablenverhalten.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung Dokumentieren Sie die Logikänderung oder Prompt-Verfeinerung, die zur Korrektur des Verhaltens verwendet wurde.
6. Erkenntnisse Geben Sie an, was der Fehler über die ursprüngliche Steuerungsphilosophie, die Annahmen oder das Sequenzdesign offenbart hat.

Dies erzeugt einen kompakten Nachweis, der für Prüfer, Ausbilder oder Personalverantwortliche nützlich ist.

KI-unterstütztes SPS-Prompting ist nützlich für Gerüste, Entwürfe und die Beschleunigung der Logikstruktur im ersten Durchlauf. Es reicht nicht aus für Sicherheitsvalidierungen, Abnahmen bei der Inbetriebnahme oder standortspezifische Einsatzentscheidungen.

Diese Grenze ist sowohl für die Ethik als auch für die Technik wichtig. Das OLLA Lab wird hier als webbasierter, interaktiver Kontaktplan- und Digital-Twin-Simulator mit geführter Unterstützung durch Yaga, 3D/WebXR/VR-Simulationen, szenariobasierten Übungen, Analog- und PID-Tools sowie Ausbilder-Workflows beschrieben. Diese Funktionen machen es als Übungs- und Validierungsumgebung nützlich. Sie wandeln generierte Logik nicht durch Assoziation in genehmigte Anlagenlogik um.

Einige Grenzen sollten explizit bleiben:

• KI-generierter Kontaktplan kann syntaktisch plausibel und funktional unsicher sein.
• Simulation kann viele Logikfehler aufdecken, ist aber nicht identisch mit der Inbetriebnahme vor Ort.
• Die Validierung des digitalen Zwillings hängt von der Modelltreue und dem Szenarioumfang ab.
• Funktionale Sicherheitsverpflichtungen erfordern weiterhin formale Methoden, kompetente Überprüfung und eine normgerechte Lebenszyklusdisziplin.

Dies steht im Einklang mit der breiteren Sicherheitsliteratur. IEC 61508 und verwandte Leitlinien behandeln systematische Fehler, Spezifikationsfehler und Verifizierungsdisziplin als zentrale Anliegen. Ein Modell, das schnell Code produziert, entbindet nicht von diesen Pflichten.

Dieser Ansatz ist nützlicher, weil er die Aufgabe von unbeschränkter Generierung zu begrenztem Engineering verschiebt. Wenn Sie zuerst eine Steuerungsphilosophie schreiben, zwingen Sie die wichtigen Entscheidungen ans Licht: sicherer Zustand, Freigaben, Abschaltungen, Sequenzverantwortung und Fehlerreaktion.

Das hat drei praktische Vorteile:

• besseres Gerüst im ersten Durchlauf,
• schnelleres Debugging in der Simulation,
• klarere Überprüfung durch Menschen.

Es lehrt auch die richtige Gewohnheit. Der berufliche Übergang besteht nicht nur darin, von „kein Kontaktplan-Wissen“ zu „Kontaktplan-Wissen“ zu gelangen. Er besteht darin, von „Sprossen schreiben“ zu „Verhalten verteidigen“ überzugehen.

- IEC 61131-3 standard overview (PLCopen) - NIST AI Risk Management Framework (AI RMF 1.0) - W3C Web Content Accessibility Guidelines (WCAG) 2 overview - IEEE taxonomy and publications portal - ISO/IEC 23894 AI risk management standard page