Wie man ein 1.000-seitiges SPS-Handbuch für einen KI-Copiloten kontextuell aufbereitet

Context Packing (kontextuelle Aufbereitung) in der industriellen Automatisierung ist die strukturierte Übertragung von Steuerungsbeschränkungen, E/A-Definitionen, Herstellersprache und Betriebslogik in einen KI-Workflow. Dies ist entscheidend, da große Sprachmodelle kritische Details in langen OEM-Handbüchern übersehen können, während domänenspezifische Systeme wie Yaga diesen Abrufaufwand durch die Nutzung vorindizierter industrieller Kontexte und Live-Simulationszustände reduzieren.

Allgemeine KI scheitert bei SPS-Aufgaben nicht, weil Handbücher einfach nur umfangreich sind. Sie scheitert, weil Steuerungsdokumente dicht, vielschichtig und operativ ungleichmäßig sind: Eine Seite enthält eine Einbaumaße, die nächste eine Auslöseschwelle, die einen Prozess stoppen kann. Token-Kapazität ist nicht gleichbedeutend mit ingenieurtechnischem Urteilsvermögen.

In einem internen Benchmark von Ampergon Vallis aus dem Jahr 2026 produzierte die Ausgabe eines allgemeinen LLM bei 41 % der Ladder-Logic-Generierungsaufgaben Syntax- oder Tag-Referenzfehler, wenn sie mit einem 1.200-seitigen OEM-Antriebshandbuch gepromptet wurde. Im Gegensatz dazu reduzierten Yaga-gestützte Workflows in OLLA Lab diese Rate für dieselbe begrenzte Aufgabenklasse auf 2,4 %. Methodik: n=84 Prompt-Response-Aufgaben; Aufgabendefinition = Generierung oder Überarbeitung von Kontaktplan-Logik (Ladder Logic) für Antriebsfreigaben, Fehler und Betriebszustandsbehandlung; Basis-Vergleich = allgemeines Frontier-LLM mit manuellem, aus PDF abgeleitetem Prompting; Zeitfenster = Jan.–Feb. 2026. Dies stützt eine eng gefasste Aussage über die Fehlerreduzierung in einem definierten Workflow. Es beweist keine universelle Überlegenheit über alle SPS-Aufgaben, Hersteller oder Modelle hinweg.

Das praktische Problem ist bekannt: Ingenieure brauchen nicht mehr Worte von einem Copiloten; sie brauchen die richtige Einschränkung, um den Scan-Zyklus zu überstehen. Das ist ein kleineres und weniger glamouröses Problem. Aber es ist dasjenige, auf das es ankommt.

Context Packing ist die bewusste Strukturierung von Maschinen-, Prozess- und Programmierbeschränkungen, damit ein KI-System Steuerungslogik anhand der tatsächlichen Betriebsrealität des Systems generieren oder bewerten kann. In der Steuerungstechnik bedeutet dies, dem Modell die Fakten bereitzustellen, die bestimmen, ob eine Logik lediglich plausibel oder tatsächlich einsatzfähig ist.

Eine nützliche operative Definition lautet: Context Packing ist die Umwandlung von verstreutem Ingenieurwissen in eine begrenzte, promptbare Spezifikation. Diese Spezifikation sollte der KI mitteilen, was das System ist, wie es sich verhalten darf, welche Tags existieren, welche Zustände zulässig sind und welche Fehlermodi Vorrang haben müssen.

Dies ist nicht dasselbe wie das Anhängen eines PDFs. Das Hochladen eines Handbuchs gibt dem Modell Zugriff auf Text. Es garantiert jedoch keine Prioritätsgewichtung, kein Verständnis von Abläufen und keine Argumentation über sichere Zustände. Semantisches Retrieval ist keine Steuerungsphilosophie. Die Unterscheidung ist trocken, aber teuer, wenn sie ignoriert wird.

Was sind die drei Säulen eines Automatisierungs-Prompts?

Ein brauchbarer Automatisierungs-Prompt benötigt in der Regel drei Säulen:

• Hardware-Beschränkungen
• Steuerungsfamilie und Programmierumgebung
• Scan-Verhalten und Ausführungsannahmen
• Verfügbarer Speicher oder Tag-Modell
• Physikalische E/A-Eigenschaften
• Gerätespezifische Register, Statuswörter und Fehlerbits

• Steuerungsphilosophie
• Ablaufsteuerung
• Freigaben und Verriegelungen
• Fail-Safe-Zustände
• Alarm- und Auslöseverhalten
• Verhalten im Hand- versus Automatikbetrieb
• Wiederanlaufbedingungen nach Fehler oder Stromausfall

- Verwendete IEC 61131-3-Sprache: KOP, ST, FBS, AS usw.

• Herstellersprache (Dialekt)
• Plattformspezifische Syntax und Adressierung
• Bevorzugte oder untersagte Befehle
• Namenskonventionen und Tag-Strukturen

Mit anderen Worten: Das Modell muss sowohl die Grammatik als auch die Anlage kennen. Das eine ohne das andere führt zu elegantem Unsinn.

Allgemeine KI-Copiloten scheitern, weil der Zugriff auf lange Kontexte keine stabile Abfrage des richtigen Details zum richtigen Zeitpunkt garantiert. Aktuelle NLP-Arbeiten zum „Lost-in-the-Middle“-Effekt zeigen, dass die Genauigkeit des Abrufs bei Modellen abnehmen kann, wenn kritische Informationen innerhalb langer Kontexte vergraben sind, anstatt am Anfang oder Ende des Prompts zu stehen (Liu et al., 2024). Das ist direkt relevant für OEM-Dokumentationen, wo das eine entscheidende Register zwischen Installationshinweisen und Wartungstabellen liegen kann.

OEM-Handbücher sind zudem strukturell feindselig gegenüber naivem Prompting. Sie kombinieren typischerweise:

• mechanische Installationsdetails,
• Schaltpläne,
• Parameterkarten,
• Protokolltabellen,
• Inbetriebnahmeverfahren,
• Alarmdefinitionen,
• Sicherheitshinweise,
• und verstreute Softwarebeispiele.

Ein LLM weiß nicht von Natur aus, dass eine Stopp-Kategorie, eine Rückmeldung oder eine Fehler-Rücksetzbedingung Vorrang vor einer Schrankabmessung haben sollte. Wenn der Prompt diese Hierarchie nicht vorgibt, behandelt das Modell den gesamten Text als Abrufkandidaten. Das ist in erster Linie ein Sprachproblem und erst in zweiter Linie ein Steuerungsproblem.

Warum verschlimmern Herstellersprachen das Problem?

Herstellerspezifische Variationen zerstören die Illusion, dass IEC 61131-3 allein ausreicht. Die Norm definiert Sprachfamilien und Konzepte, aber die praktische Umsetzung ist stark vom Hersteller geprägt.

Beispiele:

- Rockwell-Umgebungen verlassen sich oft auf Tag-basierte Strukturen wie `Local:1:I.Data`.

• Die Speicheradressierung bei Siemens kann Formen wie `%M`, `%I` und `%Q` verwenden.
• Beckhoff TwinCAT-Workflows erwarten möglicherweise andere Benennungen, Task-Annahmen und ST-Konventionen.
• Das Verhalten von Funktionsbausteinen, Timer-Semantik und Bibliotheksanforderungen kann je nach Plattform erheblich variieren.

Ein allgemeines Modell kann syntaktisch plausiblen KOP- oder ST-Code erzeugen, der für die Zielumgebung falsch ist. Dies ist die steuerungstechnische Version davon, korrekte Grammatik im falschen Dialekt zu sprechen. Es klingt gut, bis jemand versucht, es zu kompilieren.

Warum löst RAG allein nicht die steuerungstechnische Argumentation?

Retrieval-Augmented Generation (RAG) verbessert den Dokumentenzugriff, führt aber nicht automatisch zu einer ablauf- oder sicherheitsbewussten Argumentation. RAG kann einen Absatz über eine Freigabe abrufen. Es garantiert jedoch nicht, dass das Modell diese Freigabe in den richtigen Netzwerkzweig einfügt, die richtige Dominanz über manuelle Befehle zuweist oder die beabsichtigte Startsequenz beibehält.

Bei Steuerungsaufgaben ist das Schwierige oft nicht das Finden des Satzes. Es ist die Wahrung der Logikhierarchie:

• was zuerst geschehen muss,
• was niemals gleichzeitig geschehen darf,
• was bei einem Fehler abfällt,
• und was vor einem Wiederanlauf manuell quittiert werden muss.

Diese Hierarchie ist oft implizit über mehrere Dokumente verteilt. Allgemeines RAG ist ein Abrufmechanismus, keine Denkweise für die Inbetriebnahme.

Ein spezifikationsbasierter Prompt sollte das Modell einschränken, bevor es einen einzigen Netzwerkzweig schreibt. Das Ziel ist es, Halluzinationen zu reduzieren, indem die offene Generierung durch eine begrenzte ingenieurtechnische Interpretation ersetzt wird.

Die minimale Prompt-Struktur finden Sie unten.

| Prompt-Abschnitt | Ingenieurtechnischer Input | Erwartung an KI-Output | |---|---|---| | Rollenverteilung | „Agieren Sie als Steuerungstechniker, der IEC 61131-3 Kontaktplan-Logik für eine definierte Plattform generiert.“ | Engt Stil und Sprachfamilie ein. | | Plattformdefinition | „Ziel: Rockwell Studio 5000“ oder Äquivalent | Verhindert Syntax-Drift zwischen Herstellern. | | Systembeschreibung | Beschreiben Sie Maschine oder Prozess und Betriebsziel | Verankert Logik im physikalischen Verhalten. | | Zustandsdefinition | Definieren Sie zulässige Zustände und Fehlerzustand | Verhindert willkürliche Zustandsmodelle. | | E/A-Mapping | Exaktes Tag-Wörterbuch mit Eingangs-/Ausgangstypen | Reduziert Tag-Halluzinationen. | | Freigaben und Verriegelungen | Startbedingungen, Stoppbedingungen, Auslösungen, Rückmeldungen | Wahrung der Steuerungshierarchie. | | Befehlsbeschränkungen | Erlaubte und nicht erlaubte Befehle | Vermeidet nicht-standardisierte Muster. | | Fehlerverhalten | Rücksetzregeln, Speicherregeln, Alarmbehandlung | Erzwingt Behandlung anomaler Zustände. | | Ausgabeformat | „Geben Sie eine netzwerkweise Erklärung plus Annahmen zurück“ | Verbessert die Überprüfbarkeit. |

Was sollte ein guter SPS-Prompt tatsächlich enthalten?

Ein guter SPS-Prompt sollte in dieser Reihenfolge Folgendes enthalten:

1. Zielplattform und Sprache
2. Systembeschreibung
3. Operative Definition des korrekten Verhaltens
4. Exaktes E/A- und Tag-Wörterbuch
5. Ablaufsteuerung
6. Verriegelungen, Auslösungen und Fail-Safe-Verhalten
7. Befehlsbeschränkungen
8. Erwartetes Ausgabeformat
9. Anforderung expliziter Annahmen und ungelöster Mehrdeutigkeiten

Der vierte Punkt ist wichtiger, als viele Benutzer erwarten. Wenn das Tag-Wörterbuch vage ist, wird die Ausgabe vage sein. Modelle sind großzügig mit erfundenen Tags. Anlagen sind es nicht.

Beispiel für einen kompakten spezifikationsbasierten Prompt

Sprache: KI-Prompt-Struktur

SYSTEM: Sie generieren IEC 61131-3 Kontaktplan-Logik für eine Motorsteuerungsroutine.

PLATTFORM: Nur Rockwell Studio 5000 Kontaktplan-Logik.

SYSTEMBESCHREIBUNG: Steuerung eines 3-Phasen-Motors mit Start-/Stopp-Tastern, Überlastfehler, Betriebsrückmeldung und HOA-Wahlschalter. Der Motor darf nur in AUTO oder HAND laufen, wenn kein Fehler aktiv ist. In AUTO kommt der Laufbefehl von Process_Run_Request. In HAND steuert der lokale Start_PB den Lauf, aber Überlast und Not-Halt haben weiterhin Vorrang.

OPERATIVE DEFINITION VON KORREKT:

• Motor startet nur, wenn Freigaben wahr sind.
• Jeder Not-Halt oder jede Überlast schaltet den Ausgang sofort ab.
• Verlust der Betriebsrückmeldung nach Startverzögerung löst Fehler aus und schaltet Befehl ab.
• Fehler-Rücksetzung erfordert Reset_PB und das Beheben aller unsicheren Bedingungen.

E/A-MAPPING: Start_PB, Stop_PB, Reset_PB, HOA_Auto, HOA_Hand, EStop_OK, OL_OK, Run_Fbk, Process_Run_Request, Motor_Cmd, Motor_Fault

BESCHRÄNKUNGEN:

• Verwenden Sie Selbsthaltelogik, kein Setzen/Rücksetzen (Latch/Unlatch).
• Trennen Sie Freigabe-Netzwerk von Befehls-Netzwerk.
• Zeigen Sie das Netzwerk zur Fehlererkennung.
• Erfinden Sie keine Tags.

AUSGABE: Geben Sie die netzwerkweise Logikabsicht, Tag-Verwendung und Annahmen zurück, die eine Überprüfung durch einen Ingenieur erfordern.

Dies macht ein allgemeines Modell nicht deterministisch, aber es macht es weniger frei in der Improvisation. In der Steuerungstechnik ist das ein Fortschritt.

Simulationsbereit sollte operativ definiert werden, nicht rhetorisch. Eine Steuerungsroutine ist simulationsbereit, wenn ein Ingenieur ihr Verhalten unter realistischen Prozessbedingungen beweisen, beobachten, diagnostizieren und härten kann, bevor sie ein reales System erreicht.

Das bedeutet, die Logik hat die Syntax hinter sich gelassen und ist in die Validierung übergegangen. Der entscheidende Unterschied ist Syntax versus Einsatzfähigkeit.

Eine Überprüfung auf Simulationsbereitschaft sollte diese Fragen beantworten:

• Kann die Logik gegen ein realistisches Anlagenmodell ausgeführt werden?
• Können Eingänge geschaltet und Ausgänge im zeitlichen Ablauf beobachtet werden?
• Können Analogwerte, Timer, Zähler und PID-bezogenes Verhalten inspiziert werden?
• Können anomale Zustände gezielt injiziert werden?
• Kann der Ingenieur nachvollziehen, warum sich ein Ausgang geändert hat, nicht nur, dass er sich geändert hat?
• Kann die Logik nach einem Fehler überarbeitet und unter denselben Bedingungen erneut getestet werden?

Hier bleiben viele KI-Workflows schwach. Sie produzieren Logik-Kandidaten, aber sie produzieren nicht von Natur aus ingenieurtechnische Nachweise.

Welche ingenieurtechnischen Nachweise sollten Sie aufbewahren?

Wenn Sie echte Kompetenz demonstrieren wollen, bauen Sie einen kompakten Bestand an ingenieurtechnischen Nachweisen auf, anstatt eine Screenshot-Galerie zu erstellen. Verwenden Sie diese Struktur:

1. Systembeschreibung Definieren Sie Maschine oder Prozess, Betriebsziel und Umfang.
2. Operative Definition von „korrekt“ Geben Sie an, was bei normalen Bedingungen, beim Start, beim Stopp und bei Fehlerzuständen geschehen muss.
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die Logik zusammen mit den simulierten E/A oder dem Anlagenverhalten.
4. Der injizierte Fehlerfall Dokumentieren Sie die gezielt herbeigeführte anomale Bedingung.
5. Die vorgenommene Überarbeitung Protokollieren Sie die Logikänderung und warum sie notwendig war.
6. Gelernte Lektionen Halten Sie fest, was der Test über Abläufe, Verriegelungen oder Diagnosen aufgedeckt hat.

Diese Struktur ist nützlich, weil sie Argumentation zeigt, nicht nur Output. Jeder kann ein Netzwerk posten. Die schwierigere und wertvollere Aufgabe ist es zu beweisen, warum es einen „schlechten Tag“ übersteht.

Yaga reduziert das manuelle Context Packing, indem es innerhalb einer begrenzten industriellen Umgebung arbeitet, anstatt als allgemeines Textmodell, das vom zu testenden System losgelöst ist. Der wichtige Punkt ist nicht, dass es „alles weiß“. Es ist, dass es mit vorindiziertem industriellen Kontext und dem aktiven Zustand der Simulation arbeitet.

Operativ sollte Yaga als ein domänenspezifischer, vorindizierter RAG-Workflow verstanden werden, der mit der internen Kontaktplan- und Simulationsumgebung von OLLA Lab verbunden ist. Das bedeutet, der Benutzer startet nicht mit einem leeren Prompt und einem Stapel PDFs. Der Assistent kann sich beziehen auf:

• die aktive Kontaktplan-Logik,
• aktuelle Variablen- und Tag-Zustände,
• szenariospezifische Steuerungsmuster,
• geführten Lernkontext,
• und das simulierte Anlagenverhalten, das an dieses Szenario gebunden ist.

Dies ist ein engeres Problem als „industrielle KI“ im Abstrakten, was genau der Grund ist, warum es nützlicher ist.

Was ändert Yaga tatsächlich im Workflow?

Yaga ändert den Workflow von der manuellen Kontextzusammenstellung hin zur kontextbewussten Überprüfung innerhalb des Labs.

Anstatt ein allgemeines Modell zu fragen, was eine Pumpen-Folgeschaltung wahrscheinlich bedeutet, kann der Ingenieur oder Lernende in einem Szenario arbeiten, in dem der Systemkontext bereits existiert. Dies kann Ziele, E/A-Mapping, Gefahren, Ablaufanforderungen, Analog-/PID-Bindungen und Inbetriebnahmeanmerkungen umfassen, die in der Lab-Umgebung definiert sind.

In der Praxis hilft das bei Aufgaben wie:

• Überprüfung eines Netzwerks gegen das aktive Szenario,
• Nachverfolgung, warum ein Ausgang nicht angesteuert wurde,
• Prüfung, ob eine Freigabekette unvollständig ist,
• Vergleich des Kontaktplan-Zustands mit der simulierten Anlagenreaktion,
• und Überarbeitung der Logik nach einer Fehlerinjektion.

Hier wird OLLA Lab operativ nützlich. Es ist keine Abkürzung zur Standortkompetenz, SIL-Qualifizierung oder formalen Zertifizierung. Es ist eine begrenzte Übungsumgebung für die Teile der Inbetriebnahme, die zu riskant, zu teuer oder zu störend sind, um sie beiläufig an realen Anlagen zu üben.

Warum ist der Live-Simulationszustand besser als ein riesiger Prompt?

Der Live-Simulationszustand ist besser, weil er zum Zeitpunkt der Analyse strukturierten, relevanten Kontext liefert. Ein riesiger Prompt ist statisch und vom Benutzer kuratiert. Der Simulationszustand ist dynamisch und an beobachtbares Verhalten gebunden.

Diese Unterscheidung ist wichtig in Szenarien mit:

• Freigaben, die in einem Scan wahr und im nächsten falsch sind,
• Rückmeldungen, die nach einem Befehl ausfallen,
• Analogwerten, die Alarmschwellen überschreiten,
• PID-bezogenem Verhalten unter sich ändernden Prozessbedingungen,
• und Ablaufschritten, die vom vorherigen Zustandsverlauf abhängen.

Ein manueller Prompt kann diese Dinge beschreiben. Eine Simulation kann sie aufdecken. Letzteres lehrt meist mehr und führt weniger in die Irre.

Wenn Sie einen allgemeinen Copiloten verwenden müssen, reduzieren Sie die Problemgröße aggressiv. Bitten Sie das Modell nicht, „das Handbuch zu lesen und das Programm zu schreiben“. Bitten Sie es, an einem begrenzten Steuerungsproblem mit expliziten Beschränkungen zu arbeiten.

Ein praktischer Workflow ist:

• Extrahieren Sie nur die relevanten Handbuchabschnitte.
• Fassen Sie das Geräteverhalten in Ihrer eigenen Ingenieurssprache zusammen.
• Erstellen Sie eine exakte Tag-Liste.
• Definieren Sie zulässige Zustände und Fehlerzustand.
• Geben Sie die erforderliche Sequenz und Auslöselogik an.
• Verlangen Sie vom Modell, Annahmen aufzulisten.
• Überprüfen Sie jedes Netzwerk gegen die Steuerungsphilosophie.
• Testen Sie das Ergebnis in der Simulation, bevor Sie es hardwarenah verwenden.

Trennen Sie außerdem die Generierung von der Überprüfung. Verwenden Sie das Modell zuerst, um eine Kandidatenstruktur zu entwerfen, und bitten Sie es dann in einem zweiten Durchgang, unsichere Annahmen, fehlende Verriegelungen oder herstellerspezifische Syntaxrisiken zu identifizieren. Einmaliges Prompting führt tendenziell schneller zu Vertrauen als zu Qualität. Die Maschine ist deswegen nicht verlegen.

Mehrere Normen und Forschungsbereiche sind relevant, aber sie gelten unterschiedlich.

• IEC 61131-3 ist wichtig für SPS-Programmiersprachenfamilien und die Implementierungsstruktur.
• IEC 61508 ist wichtig für das Denken im Lebenszyklus der funktionalen Sicherheit, insbesondere im Hinblick auf systematische Strenge, Verifizierung und Validierung. Es bedeutet nicht, dass eine KI-generierte Routine automatisch sicherheitskonform ist.
• Literatur zu Digitalen Zwillingen und Simulation ist wichtig, da virtuelle Validierung das Verständnis von Systemverhalten, Fehlerreaktion und Trainingseffektivität verbessern kann, wenn sie mit realistischen Modellen verknüpft ist.
• Forschung zu LLM-Langkontexten ist wichtig, da eine Verschlechterung des Abrufs beeinflusst, ob vergrabene technische Beschränkungen tatsächlich verwendet werden.

Die wichtigste Warnung ist einfach: Normen können die Prozessdisziplin leiten, aber sie segnen keine generierte Logik ab. Validierung muss immer noch verdient werden.

OLLA Lab passt als webbasierte Übungs- und Validierungsumgebung für Kontaktplan-Logik, simuliertes Anlagenverhalten und geführte Fehlersuche. Sein Wert ist dort am größten, wo der Benutzer Code mit Maschinenreaktion verbinden muss, anstatt nur Syntax zu produzieren.

Richtig begrenzt unterstützt OLLA Lab Ingenieure und Lernende, die üben müssen:

• Kontaktplan-Logik in einem browserbasierten Editor zu erstellen,
• Simulationen sicher ohne physische Hardware auszuführen,
• Variablen, E/A, Analogwerte und PID-bezogenes Verhalten zu überwachen,
• realistische industrielle Szenarien durchzuarbeiten,
• und Yaga als kontextuellen Coach statt als Orakel zu nutzen.

Das ist eine glaubwürdige Rolle. Es ist auch die richtige. In der Steuerungstechnik sollten Werkzeuge Vertrauen verdienen, indem sie Fehlermodi eingrenzen, nicht indem sie vorgeben, sie abgeschafft zu haben.

Um dieses Thema in den breiteren Wandel hin zur KI-gestützten Technik einzuordnen, lesen Sie unseren Hub zur Zukunft der Automatisierung.

Für eine tiefergehende Behandlung des Schreibens von Steuerungsabsichten vor dem Code, siehe Spec-Driven Scaffolding: Using AI to Generate Control Narratives.

Für plattformspezifische Argumentation und Syntaxdisziplin, lesen Sie Vendor-Aware Agents: Bridging the Gap Between LLMs and Real PLCs.

Wenn Sie dies in einer begrenzten Umgebung testen möchten, öffnen Sie ein Motorsteuerungsszenario in OLLA Lab und nutzen Sie Yaga, um die Logik anhand des Live-Simulationsverhaltens zu überprüfen.

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