Automatisierte SPS-Programmierung mit LLM-Agenten

Vorgestellt auf dem Automation Kongress 2025 — Paper herunterladen

Autoren: R. Kimmel (Universität Stuttgart), Dr. B. Wiesmayr (JKU Linz), Univ.-Prof. Dr. A. Wortmann (Universität Stuttgart)

---

Das Problem: SPS-Entwicklung ist aufwendig und fehleranfällig

Speicherprogrammierbare Steuerungen (SPS) sind das Herzstück moderner Automatisierungsanlagen. Sie steuern Förderbänder, Roboter, Fertigungslinien — überall dort, wo Prozesse automatisiert ablaufen. Programmiert werden sie meist nach dem IEC 61131-3-Standard in sogenanntem Strukturiertem Text.

Das Problem: Diese Arbeit ist Domänenexperten vorbehalten, nicht klassischen Softwareentwicklern. Wer SPS-Code schreibt, muss Maschinenkenntnisse, Prozesswissen und Programmierfähigkeiten vereinen. Der Entwicklungsprozess ist zeitintensiv, fehleranfällig — und angesichts des Fachkräftemangels zunehmend zum Engpass geworden.

Genau hier setzt unser Forschungskonzept an.

Die Kernidee: Ein LLM-Agent als Programmier-Assistent

Unser Konzept setzt einen Large Language Model-Agenten als zentralen Prozessorchestrateur ein. Der Agent empfängt Anforderungen des Domänenexperten in natürlicher Sprache — und erzeugt daraus eigenständig Steuerungscode.

Ablauf des iterativen Code-Generationsprozesses mit dem LLM-Agenten im Zentrum

Der Agent handelt schrittweise nach einem festen Schema: Er formuliert einen Gedanken, wählt ein Werkzeug aus (z.B. "Write File", "Read File", "Set Task") und wertet das Ergebnis aus — analog zu einem menschlichen Entwickler, der Schritt für Schritt vorgeht.

Die vier Forschungsfragen

RQ1: Wie interagiert der Agent mit seiner Umgebung?

Der Agent benötigt Zugriff auf eine SPS-Entwicklungsumgebung (in unserem Konzept: Beckhoff TwinCAT). Über eine definierte Werkzeugmenge kann er: ▸ Dateien lesen und schreiben ▸ Projekte kompilieren ▸ Tests auslösen und Ergebnisse auswerten

Ein Parser extrahiert aus der Textausgabe des LLM die strukturierten Felder (Werkzeug, Eingabe, Gedanke) und übergibt sie an das entsprechende Werkzeug.

RQ2: Wie wird die Wissensbasis modelliert?

Ein Kernproblem: LLMs kennen IEC 61131-3-Syntax grundsätzlich aus dem Vortraining — aber maschinenspezifische Parameter, Anschlüsse, Unternehmensrichtlinien und Prozessdetails sind ihnen unbekannt.

Unser hybrider Ansatz kombiniert: ▸ Vektordatenbanken (z.B. Chroma) für semantische Ähnlichkeitssuche auf Textdokumenten ▸ SQL-Datenbanken (z.B. PostgreSQL) für strukturierte Maschinenparameter ▸ Graphdatenbanken / Ontologien (z.B. Neo4j, OWL) für Beziehungen zwischen Wissenselementen ▸ Standardisierte Metamodelle (OPC UA, AAS, SysML) für Systemarchitekturen

Das Wissen bleibt extern — damit bleibt das System flexibel: Neue LLMs können sofort auf dieselbe Wissensbasis zugreifen, ohne Retraining. Änderungen an Maschinenparametern oder Firmenpolicen lassen sich punktuell einspielen.

RQ3: Wie wird der Code validiert?

Syntaktische Korrektheit prüft der Compiler automatisch. Aber das reicht nicht: SPS-Code steuert physische Prozesse — ein Bug kann zu Produktionsausfällen oder Sicherheitsrisiken führen.

Deshalb setzt unser Konzept auf Virtuelle Inbetriebnahme (VIBN): Der generierte Code läuft gegen ein digitales Modell der realen Anlage (Simulation via ISG Virtuos) unter Echtzeitbedingungen. So werden nicht nur logische, sondern auch physikalische Effekte getestet — noch bevor die reale Maschine verfügbar ist.

RQ4: Wie wird Feedback für das LLM aufbereitet?

Simulationsergebnisse liefern Rohdaten: Positionsabweichungen, Zeitreihen, Boolean-Flags. Diese sind für ein Sprachmodell direkt nicht interpretierbar.

Zwei Ansätze sind denkbar: ▸ Regelbasierte Übersetzung: Automatisch generierte Fehlerbeschreibungen wie "Werkstück wird zu langsam transportiert" aus numerischen Messwerten ▸ Fine-Tuning: Das LLM lernt, Simulationsdaten direkt semantisch zu interpretieren

Durch diesen Feedbackkreis kann der Agent iterativ verbessern — ähnlich einem menschlichen Entwickler, der testet, den Fehler analysiert und den Code anpasst.

Warum kein vollständiges Retraining?

Ein zentrales Designprinzip: Das Domänenwissen bleibt außerhalb des Modells. Das hat entscheidende Vorteile für industrielle Anwendungen:

▸ Maschinenparameter ändern sich? → Wissensbasis aktualisieren, kein Retraining ▸ Besseres LLM verfügbar? → Einfach austauschen, Wissensbasis bleibt ▸ Neue Unternehmensrichtlinien? → Direkt in die Datenbank einspielen

Relevanz für Zelos Digital Solutions

Dieses Forschungskonzept ist Teil unserer Industrial Business AI-Lösungen. Das Prinzip — LLM-Agenten, die auf strukturiertes Unternehmenswissen via RAG zugreifen, mit internen Systemen interagieren und iterativ verbessern — wenden wir in verschiedenen industriellen Kontexten an: von automatisierten Dashboards bis hin zu agentenbasierten Workflows, die direkt in bestehende Softwarelandschaften eingebunden werden.

Paper herunterladen: Automation Kongress 2025 – R. Kimmel et al. (PDF)