KI in der SPS-Programmierung: was im TIA Portal heute geht

Kurz beantwortet: KI kann heute im TIA Portal Bausteine in SCL und FUP erzeugen, übersetzen, gegen eine Funktionsbeschreibung prüfen, in der Simulation testen und die Dokumentation nachführen. Verlässlich wird das erst in einem festen Ablauf: Am Anfang steht eine mit dem Auftraggeber abgestimmte Funktionsbeschreibung, am Ende der Test in der Simulation. Sicherheitsgerichtete Programmteile schreibt der Ingenieur selbst, und in eine reale CPU lädt immer ein Mensch.

Dieser Artikel richtet sich an Einkäufer, Projektleiter und Instandhaltungsleiter, die entscheiden müssen, ob sie ein Steuerungsprojekt an einen Dienstleister mit KI-gestütztem Engineering vergeben. Er beschreibt, wie wir in unserem Ingenieurbüro mit KI-Agenten arbeiten, wo wir bewusst Grenzen ziehen, was hinter den häufigsten Einwänden steckt und wie sich der Siemens Eigen Engineering Agent davon unterscheidet.

1.Chatfenster oder Werkzeugkette: zwei Arten von KI in der SPS-Programmierung

Wer „KI und SPS“ hört, denkt meist an ein Chatfenster: Man beschreibt eine Aufgabe, bekommt SCL-Code zurück und kopiert ihn ins Projekt. Für kleine, abgeschlossene Funktionen kann das reichen. Für ein Anlagenprogramm reicht es nicht, denn das Modell kennt das Projekt nicht, übersetzt nichts und testet nichts. Ob der Code zu den vorhandenen Datentypen, Bausteinschnittstellen und Namenskonventionen passt, bleibt Handarbeit.

Die zweite Art sind KI-Agenten, die direkt im Engineering-Werkzeug arbeiten, statt Code aus einem Chatfenster zu liefern. Sie kennen die Struktur des Projekts, bekommen die Rückmeldungen des Compilers und können darauf reagieren. Sie arbeiten im Projekt, nicht daneben. An diesem Unterschied entscheidet sich, ob KI in der SPS-Programmierung eine Spielerei bleibt oder ein Werkzeug wird.

2.So setzen wir KI-Agenten im TIA Portal ein

Bei uns arbeiten KI-Agenten direkt im TIA Portal. Der Ablauf ist in jedem Projekt derselbe:

1. Funktionsbeschreibung zuerst. Vor der ersten Zeile Code steht eine Funktionsbeschreibung (FDS), die mit Ihnen abgestimmt ist. Sie ist der Maßstab für alles, was danach kommt.
2. Bausteine erzeugen und übersetzen. Die Agenten erzeugen SCL für Berechnungen und Datenverarbeitung und FUP für Verknüpfungslogik und übersetzen das Projekt. Meldet der Compiler Fehler, geht der Baustein zurück in die Überarbeitung.
3. Review gegen die Funktionsbeschreibung. Jeder Baustein wird mit der FDS abgeglichen: Ist jede beschriebene Funktion umgesetzt, und tut der Code nichts, was dort nicht steht?
4. Funktionstest in der Simulation. Das Programm läuft auf einer simulierten Steuerung. Die Tests lassen sich nach jeder Änderung wiederholen.
5. Test der Bedienung. Die Bedienung der Visualisierung wird gegen die simulierte Steuerung geprüft, so wie sie später der Bediener nutzt: Taster betätigen, Meldung quittieren, Sollwert ändern, Reaktion prüfen.

Die Visualisierung entsteht dabei aus der SPS-Struktur. Bilder, Alarme und Variablen für WinCC Unified werden aus Bausteinen und Datentypen generiert, ebenso die Migration bestehender Comfort-Panel-Projekte nach Unified. Mehr dazu auf der Seite HMI-Visualisierung mit WinCC Unified. Wie wir Steuerungsprogramme aufbauen und übergeben, beschreibt die Seite SPS-Programmierung im TIA Portal, den Test vor der Inbetriebnahme die Seite Inbetriebnahme mit End-to-End-Test.

Ein Beispiel für Vorarbeit, die sonst Tage binden kann: Aus einem Schaltplan als PDF erzeugen die Agenten eine E/A-Liste und daraus die Symboltabelle für das TIA Portal. Gemessen haben wir das an einem Plan mit 51 Seiten, der nach rund elf Minuten durchgearbeitet war. Geprüft wird das Ergebnis danach trotzdem gegen den Plan.

3.Bestandsanlagen: Re-Dokumentation ohne Symbolik

Der größte Nutzen liegt oft nicht bei Neuanlagen, sondern im Bestand. Viele S7-300-Steuerungen laufen seit Jahrzehnten mit einem Programm, von dem nur noch ein Online-Abzug existiert: AWL-Code ohne Symbolik und ohne Kommentare, Merker und Datenbausteine als nackte Adressen. Wer eine solche Anlage modernisieren will, muss zuerst verstehen, was sie tut.

Für diese IST-Analyse lesen die Agenten den Bestandscode Baustein für Baustein, verfolgen Signale über Bausteingrenzen hinweg und leiten daraus eine Funktionsbeschreibung ab. Dabei gilt unsere strengste Regel, die Belegpflicht: Jede Aussage über die Anlage muss sich auf eine Stelle im Code oder in den Unterlagen zurückführen lassen. Was sich nicht belegen lässt, steht als offene Frage im Dokument und wird an der Anlage oder mit dem Betreiber geklärt. Das Modell füllt solche Lücken nicht mit plausiblen Vermutungen.

Aus der Funktionsbeschreibung entsteht anschließend das neue Programm, bei Migrationen bevorzugt in FUP und KOP, damit die Instandhaltung im Online-Status sieht, welche Bedingung fehlt. Diesen Weg gehen wir beim Steuerungs-Retrofit von S5 und S7-300 ebenso wie bei der Migration von CODESYS ins TIA Portal. Was eine brauchbare Anlagendokumentation enthalten sollte, beschreibt der Beitrag SPS-Dokumentation.

4.Leitplanken: was die KI bei uns nicht darf

Ein Fehler im Steuerungsprogramm ist kein Schönheitsfehler. Ein Teilnehmer im Forum r/PLC hat es so formuliert: „In our industry, a 99% success rate is a catastrophic failure.“ In unserer Branche ist eine Trefferquote von 99 Prozent also ein Totalausfall. Aus meiner Erfahrung in der Inbetriebnahme kann ich das nur unterschreiben. Deshalb gelten bei uns fünf Regeln, ohne Ausnahme:

• Keine Programmierung ohne Funktionsbeschreibung. Ohne abgestimmte FDS gibt es keinen Maßstab, gegen den sich ein Ergebnis prüfen ließe.
• Alles wird in der Simulation getestet. Kein Baustein wird ausgeliefert, der nicht in der Simulation getestet wurde.
• Safety bleibt beim Ingenieur. Sicherheitsgerichtete Programmteile programmiert der Ingenieur selbst und validiert sie auf klassischem Weg.
• In die reale CPU lädt ein Mensch. Das Laden auf die Anlage ist immer ein bewusster Schritt eines Menschen, nie der eines Agenten.
• Bei Bestandsanlagen gilt Belegpflicht. Was nicht belegt ist, gilt als offen.

5.Warum KI die Qualität hebt, nicht nur das Tempo

In der Debatte über KI geht es meist um Zeitersparnis. Für den Auftraggeber ist ein anderer Effekt oft wichtiger: Es wird mehr geprüft.

Mehr Tests. In vielen klassischen Projekten wird ein großer Teil erst bei der Inbetriebnahme getestet, unter Zeitdruck und an der Anlage. Tests in der Simulation lassen sich dagegen nach jeder Änderung wiederholen. Was einmal funktioniert hat, geht durch eine spätere Änderung nicht unbemerkt verloren.

Bessere Vorarbeit. E/A-Listen, Symboltabellen und Meldetexte kosten Ingenieurstunden, die dann bei der eigentlichen Anlagenlogik fehlen. Übernimmt der Agent das Abtippen, bleibt mehr Zeit für die Fragen, die Erfahrung brauchen: Was passiert bei Drahtbruch? Wie läuft die Anlage nach einem Spannungsausfall wieder an?

Dokumentation, die zum Programm passt. Funktionsbeschreibung, Programm und Visualisierung entstehen aus derselben Quelle. Ändert sich das Programm, wird die Dokumentation im selben Zug nachgeführt, statt am Projektende aus dem Gedächtnis nachgeschrieben zu werden.

Wie viel Zeit das im Gesamtprojekt spart, beziffern wir bewusst nicht. Gemessen haben wir einzelne Schritte wie die E/A-Liste oben. Wie groß der Effekt über ein ganzes Projekt ist, hängt von Anlage, Unterlagen und Zustand des Bestandscodes ab.

6.Die Einwände der Einkäufer und was dahintersteckt

Die Vorbehalte gegenüber KI sind gut dokumentiert. Für die Studie Künstliche Intelligenz 2025 hat Bitkom 604 Unternehmen befragt. Als Hürden nannten 53 Prozent rechtliche Unklarheit, 48 Prozent den Datenschutz, 39 Prozent die Sorge, dass Daten in falsche Hände geraten, 38 Prozent mangelnde Nachvollziehbarkeit und 36 Prozent die Qualität der Ergebnisse. Im Maschinenbau zeigt sich ein ähnliches Bild: In einer KI-Umfrage des VDMA nannten 39 von 144 Teilnehmern rechtliche Fragen wie Datenzugang und Haftung.

Diese Einwände sind berechtigt. Beantworten lassen sie sich nur konkret:

7.Datenschutz: was mit Ihren Projektdaten geschieht

Ein TIA-Projekt enthält das Prozesswissen einer Anlage. Entsprechend gelten bei uns feste Regeln:

• Kein Training mit Ihren Daten. Ihre Projektdaten werden nicht zum Training von KI-Modellen verwendet.
• Eigene Systeme statt öffentlicher Chat-Tools. Projekte werden auf unseren eigenen Systemen gespeichert und nicht in öffentliche Chat-Tools kopiert.
• Datenwege vor Projektstart abgestimmt. Welche Unterlagen in die KI-gestützte Bearbeitung gehen und welche nicht, stimmen wir vor Projektbeginn mit Ihnen ab.
• Anonymisierung, wo möglich. Firmennamen, Standortbezeichnungen und andere identifizierende Angaben werden vor der Bearbeitung entfernt oder ersetzt, soweit das die Arbeit nicht behindert.
• Geheimhaltungsvereinbarung auf Wunsch. Wenn Sie es wünschen, schließen wir vor Projektbeginn eine Geheimhaltungsvereinbarung (NDA).

Das ist keine Rechtsberatung und ersetzt keine rechtliche Prüfung in Ihrem Haus. Hat Ihre IT- oder Datenschutzabteilung Vorgaben für externe Dienstleister, gehören sie in genau dieses Vorgespräch.

8.Siemens Eigen Engineering Agent: Werkzeug statt Dienstleistung

Mit dem Eigen Engineering Agent hat Siemens am 20. April 2026 den Nachfolger des Industrial Copilot for Engineering allgemein verfügbar gemacht. Siemens beschreibt ihn als KI-Lösung für SPS-Programmierung, HMI-Visualisierung und Gerätekonfiguration (Pressemitteilung). Voraussetzung sind TIA Portal V19, V20 oder V21 und ein Industry Organization Account (Produktseite). Lizenziert wird er als jährliches SaaS-Abonnement, ein Seat gilt für drei zugewiesene Nutzer (Lizenzierung). Im US-Store von Siemens kostet ein Seat 2.100 US-Dollar im Jahr (Siemens Store).

Für eine Engineering-Abteilung mit eigenen TIA-Programmierern kann das ein sinnvolles Werkzeug sein. Es sitzt in der gewohnten Umgebung, kommt vom Hersteller der Steuerung und wird von ihm gepflegt. Einordnen sollte man es als das, was es ist: ein Werkzeug für Menschen, die selbst programmieren. Funktionsbeschreibung, Tests, Abnahme und Verantwortung bleiben beim Anwender.

Zwei Punkte gehören in die Abwägung:

• Der Startpunkt ist V19. Anlagen auf S5 oder STEP 7 Classic liegen davor. Gerade dort existiert oft nur ein Online-Abzug ohne Symbolik, und das Programm muss erst verstanden und neu aufgebaut werden, bevor ein Werkzeug im TIA Portal ansetzen kann.
• Ein Werkzeug ersetzt keine Kapazität. Wer keine eigenen Programmierer hat oder sie für ein Projekt nicht freistellen kann, braucht eine Dienstleistung, kein weiteres Werkzeug.

Beides schließt sich nicht aus. Ein Betrieb kann den Agenten für eigene kleine Änderungen nutzen und ein größeres Projekt trotzdem vergeben.

9.Fünf Fragen an einen Dienstleister, der mit KI programmiert

Ob ein Anbieter KI verantwortungsvoll einsetzt, lässt sich mit wenigen Fragen klären. Die Antworten sollten konkret sein, nicht beruhigend:

1. Gibt es vor der Programmierung eine Funktionsbeschreibung, die mit uns abgestimmt wird?
2. Wie wird getestet, bevor das Programm an die Anlage geht, und welche Testergebnisse erhalten wir?
3. Wer programmiert und validiert die Safety-Funktionen?
4. Wo liegen unsere Projektdaten, gehen sie in öffentliche Chat-Tools, und wird mit ihnen KI trainiert?
5. Wer lädt das Programm in die reale Steuerung, und wer steht für das Ergebnis ein?

Bleiben die Antworten vage, fehlt meist der feste Ablauf, der KI-Ergebnisse überhaupt prüfbar macht. Die Fragen 1, 2 und 5 sollte übrigens jeder Dienstleister beantworten können, auch einer, der ganz ohne KI arbeitet.

10.Fazit: Der Ablauf entscheidet, nicht das Modell

KI in der SPS-Programmierung ist im TIA Portal praktisch einsetzbar. Ob der Einsatz nützt oder ein Risiko wird, entscheidet nicht das Modell, sondern der Ablauf drumherum: Funktionsbeschreibung vor dem Code, Test in der Simulation vor der Anlage, Safety in der Hand des Ingenieurs und ein Mensch, der das Programm in die Steuerung lädt.

Prybisch Automation ist ein Ingenieurbüro in Luxemburg für Siemens-Automatisierung (TIA Portal, WinCC Unified, Retrofit) mit KI-gestütztem Engineering, tätig in der Großregion und europaweit. Wir arbeiten als ein erfahrener Ingenieur mit einem eingespielten Setup aus KI-Agenten, das Vorarbeit, Tests und Dokumentation übernimmt. Entscheidungen und Verantwortung bleiben beim Menschen.

11.Quellen

• Bitkom Research: Künstliche Intelligenz 2025, Befragung von 604 Unternehmen
• VDMA: KI-Umfrage, 144 Teilnehmer
• Reddit r/PLC: Forenbeitrag zur Fehlertoleranz in der Automatisierung, Einzelmeinung aus der Praxis, keine Studie
• Siemens: Pressemitteilung zum Eigen Engineering Agent, Produktseite, Lizenzierung und Kauf und Siemens Store (USA)

Alle Quellen abgerufen am 26.10.2026.

---

Über den Autor: Geschrieben hat diesen Beitrag David Prybisch, Inhaber von Prybisch Automation. Prybisch Automation ist ein Ingenieurbüro in Luxemburg für Siemens-Automatisierung (TIA Portal, WinCC Unified, Retrofit) mit KI-gestütztem Engineering, tätig in der Großregion und europaweit. David Prybisch programmiert seit über zwölf Jahren Steuerungen und ist seit 20 Jahren im industriellen Umfeld tätig. Wie ein Siemens-Retrofit als Projekt abläuft, beschreibt der Beitrag S5 & S7-300 Retrofit auf S7-1500 und WinCC Unified.