Links ein offenes Testgestell mit Steuerungen, davor ein Förderband-Testmodell, das selbstständig läuft; rechts lesen zwei Ingenieure mit Kaffee und zugeklapptem Laptop auf einem Wandbildschirm die Messungen von plc-build: Schritte je Projekt und 49 von 50 Läufen ohne Eingriff

// Der Weg: Problem → Befehle → Adapter → Jenkinsfile → Grenzen → frühe Nutzung

PLC Build Tool: SPS-Builds in jeder Pipeline

Ein Kommandozeilenwerkzeug mit denselben Befehlen für TIA Portal, CODESYS, TwinCAT und Studio 5000. Jenkins, GitLab CI oder Azure DevOps rufen es auf, der Adapter spricht mit der Engineering-Umgebung, und das Ergebnis kommt einheitlich als Exit-Code und JUnit-XML zurück.

Frühen Zugang anfragen Whitepaper CI/CD mit TIA Portal

30 Minuten · unverbindlich · kein Vertriebsgespräch

IN ENTWICKLUNG · EIN BEFEHLSSATZ · VIER ADAPTER · JUNIT-XML

// 01Kurz erklärt

Was ist das PLC Build Tool?

Das PLC Build Tool ist das Stück zwischen CI-Server und Engineering-Umgebung, das bisher jedes Team selbst schreibt.

Die Hersteller liefern Programmierschnittstellen für den Build ohne Oberfläche: TIA Portal Openness, die Scripting-Schnittstelle von CODESYS, das TwinCAT Automation Interface und das Logix Designer SDK. Was eine Pipeline daraus aufruft, schreibt bisher jedes Team selbst, und wer mehrere Hersteller hat, schreibt es mehrfach. Das Build Tool hat einen Befehlssatz und je Umgebung einen Adapter, den wir mit neuen Versionen der Umgebung nachziehen.

Auf einen Blick

Art: Kommandozeilenwerkzeug für Windows, dazu eine Oberfläche für Builds, Agenten und Messungen (Prototyp)
Befehle: doctor, restore, import, compile, analyze, test, report, archive, cleanup
Adapter: Siemens TIA Portal, CODESYS, Beckhoff TwinCAT 3, Rockwell Studio 5000
Aufruf aus: Jenkins, GitLab CI, Azure DevOps und jeder Pipeline mit Windows-Agent
Ausgabe: Exit-Code, JUnit-XML, SARIF, Build-Manifest, Projektarchiv der Umgebung
Status: In Entwicklung, frühe Nutzung mit ausgewählten Teams

Entwicklungsstand · Bildschirmfotos aus dem Prototyp

/01 Build
Build #418 hält bei compile an. Die Fehler stehen mit Objektpfad und Meldung da, Exit 1 heißt: Der Befund liegt im Projekt. Das Manifest hält fest, womit gebaut wurde.
/02 Agent-Diagnose
doctor prüft den Build-Agenten, bevor ein Projekt geöffnet wird. Hier fehlt das Konto in der Gruppe „Siemens TIA Openness“. Exit 3 heißt: Die Umgebung hält den Build auf, nicht der Code, und der nächste Schritt steht daneben.
/03 Messungen
Dieselben Befehle für TIA Portal und CODESYS. Darunter, was ein Pilot belegen soll: Läufe ohne Eingriff, keine übrig gebliebenen Prozesse und die Dauer je Schritt.

Bildschirmfotos aus dem Prototyp, Entwicklungsstand Oktober 2026. PLC Build Tool ist in Entwicklung; Ansichten, Bezeichnungen und Zahlen können sich bis zur ersten Version ändern. Ein Klick auf ein Bild öffnet es in voller Größe.

// 02Ausgangslage

Woran scheitern selbst geschriebene Build-Skripte?

Am Versionswechsel. Die Programmierschnittstellen ändern sich mit der Version der Umgebung. TIA Portal V21 etwa liefert die Openness API in neuen Assemblies aus, weiterhin auf .NET Framework 4.8; Anwendungen für V17 bis V20 müssen angepasst werden. Wer für mehrere Umgebungen eigene Skripte pflegt, hat diesen Aufwand mehrfach.

Am Betrieb. Engineering-Werkzeuge sind für den Arbeitsplatz gebaut, nicht für einen Build-Agenten. Rechte, Benutzersitzungen, Lizenzen und hängende Prozesse nach einem abgebrochenen Build kosten mehr Zeit als das eigentliche Übersetzen.

An der Rückmeldung. Jede Umgebung meldet Übersetzungsfehler und Testergebnisse in eigener Form. Eine Pipeline braucht einen Exit-Code und ein Format, das der CI-Server lesen kann.

Ein Build-Skript, das jahrelang lief, bricht nach dem Update der Engineering-Umgebung ab. Wer es geschrieben hat, sitzt inzwischen in einem anderen Projekt, und bis jemand die neue Schnittstelle verstanden hat, übersetzt das Team wieder von Hand.

// 03Funktionen

Was soll das Build Tool
können?

Der geplante Funktionsumfang. PLC Build Tool ist in Entwicklung, Einzelheiten können sich bis zur ersten Version ändern.

/01
restore und import
Projekt vorbereiten, Quellen aus Git einspielen.
Der Adapter stellt das Basisprojekt aus dem Archiv der Umgebung wieder her und spielt die Textquellen aus dem Repository ein, etwa SIMATIC SD bei TIA Portal oder L5X bei Studio 5000. Bei TwinCAT liegen die Quellen schon im Projekt, der Import entfällt.
/02
compile
Übersetzen mit Exit-Code, für jede Umgebung gleich.
Der Adapter übersetzt das Projekt über die Schnittstelle der Umgebung. Jeder Fehler beendet den Aufruf mit einem Exit-Code ungleich 0, die Meldungen stehen im Log und im JUnit-Bericht.
/03
analyze
Programmierrichtlinien als Gate.
Der Adapter ruft die statische Prüfung der Umgebung auf, etwa den Style Guide Checker der TIA Portal Test Suite, CODESYS Static Analysis oder TwinCAT 3 PLC Static Analysis. Das Regelwerk liegt als Datei im Repository. Neue Regeln lassen sich zuerst als Warnung führen und erst nach der Bereinigung des Bestands als Fehler.
/04
test
Funktionstests ohne Hardware.
Der Adapter startet die Simulation oder Laufzeit der Umgebung, lädt das Projekt, führt die Testfälle aus und beendet sie wieder: S7-PLCSIM Advanced mit der TIA Portal Test Suite, den CODESYS Test Manager, TcUnit auf der TwinCAT Usermode Runtime oder eine mit Logix Echo emulierte Steuerung.
/05
report, archive, cleanup
Ergebnis zurückmelden, Stand sichern, aufräumen.
Ergebnisse aller Umgebungen gehen im selben JUnit-Format an den CI-Server. Auf dem Hauptzweig archiviert das Tool den gebauten Stand im Archivformat der Umgebung. cleanup beendet die Engineering- und Simulationsprozesse, die das Tool selbst gestartet hat, auch nach einem abgebrochenen Build.

// 04Adapter

Welche Hersteller unterstützt das Build Tool?

Geplant sind Adapter für vier Engineering-Umgebungen. Bedienung und Regeln bleiben gleich, der Adapter übernimmt, was die jeweilige Umgebung anders macht. Welche Adapter zuerst fertig werden, ist noch offen. Weitere Umgebungen lassen sich über eigene Adapter anbinden.

Umgebung	Was der Adapter tut
Siemens TIA Portal V21	Übersetzt über TIA Portal Openness, prüft mit dem Style Guide Checker und testet mit der Test Suite auf S7-PLCSIM Advanced. Application Tests gibt es für die S7-1500-Familie einschließlich ET 200SP und ET 200pro, nicht für die S7-1200, und sie brauchen eine Lizenz für die Test Suite Advanced. Bausteine und Datentypen kommen als SIMATIC SD, vollständig ab V21; Variablentabellen und Hardware bleiben im Basisprojekt.
CODESYS V3.5	Steuert CODESYS über die Scripting-Schnittstelle ohne Oberfläche, prüft mit CODESYS Static Analysis und testet mit dem CODESYS Test Manager, dessen Bericht der Adapter in JUnit umsetzt. Beide gehören zur Professional Developer Edition, die auf dem Build-Agenten lizenziert sein muss. Marken auf CODESYS-Basis mit eigener Scripting-Schnittstelle, etwa WAGO e!COCKPIT, prüfen wir je Marke und Version.
Beckhoff TwinCAT 3	Übersetzt über das TwinCAT Automation Interface, prüft mit TwinCAT 3 PLC Static Analysis und führt TcUnit-Tests auf der Usermode Runtime des Build-Agenten aus. Den früheren TcUnit-Runner pflegt niemand mehr, der Adapter bringt dafür einen eigenen Ablauf mit; das angekündigte Test Framework TF1140 von Beckhoff kommt als Option dazu.
Rockwell Studio 5000	Baut auf Rockwells offenen Werkzeugen für Git auf: Aus dem L5X wird wieder ein Projekt, übersetzt wird über das Logix Designer SDK, das erst ab Logix Designer V37 übersetzen kann. Tests prüfen Tags einer mit FactoryTalk Logix Echo emulierten Steuerung; ein Unit-Test-Framework wie in den anderen Umgebungen gibt es für Logix nicht.

// 05Beispiel

Wie sieht eine Jenkins-Pipeline mit dem Build Tool aus?

Ein Entwurf für drei SPS-Projekte verschiedener Hersteller in einer Matrix. Welcher Adapter zu welchem Projekt gehört, steht in der Konfigurationsdatei im Repository, die auch die Git Bridge liest. lock verhindert, dass zwei Builds dieselbe Simulation belegen.

Der erste rote Build meldet einen Übersetzungsfehler kurz nach dem Commit, solange der Entwickler den Baustein noch im Kopf hat, und nicht Wochen später bei der Inbetriebnahme.

Jenkinsfile

pipeline {
  agent none
  stages {
    stage('SPS-Projekte') {
      matrix {
        axes {
          axis {
            name 'PROJEKT'
            values 'linie-1/plc', 'linie-1/roboterzelle', 'verpackung/plc'
          }
        }
        agent { label 'plc-windows' }
        stages {
          stage('Build') {
            steps {
              bat "plc-build restore --project ${PROJEKT}"
              bat "plc-build import  --project ${PROJEKT}"
              bat "plc-build compile --project ${PROJEKT}"
              bat "plc-build analyze --project ${PROJEKT}"
            }
          }
          stage('Test') {
            steps {
              lock("sim-${PROJEKT}") { bat "plc-build test --project ${PROJEKT}" }
            }
          }
        }
        post {
          always {
            bat "plc-build report --project ${PROJEKT} --junit out"
            junit allowEmptyResults: true, testResults: 'out/*.xml'
            bat 'plc-build cleanup || exit 0'
          }
        }
      }
    }
  }
}

Entwurf · Befehle, Bezeichnungen und Ausgabe können sich bis zur ersten Version ändern.

// 06Grenzen

Was das Build Tool
nicht tut

/01
Das Build Tool ist kein CI-Server. Es läuft unter Jenkins, GitLab CI oder Azure DevOps, die Orchestrierung bleibt dort.
/02
Es lädt keine Software auf reale Steuerungen. Das Deployment auf die Anlage bleibt ein bewusst freigegebener Schritt.
/03
Es bringt weder Engineering-Software noch Lizenzen der Hersteller mit. Beides brauchen Sie auf dem Build-Agenten selbst.
/04
Testfälle schreibt es nicht. Die Tests entstehen im Testwerkzeug der Umgebung auf Basis Ihrer Modulspezifikation.
/05
Was eine Umgebung nicht automatisieren lässt, kann auch der Adapter nicht. Fehlt etwa für eine Steuerungsfamilie die Simulation, bleiben dort Übersetzen und statische Prüfung.

// 07Voraussetzungen

Was braucht das Build Tool?

Build-Agent: Windows-VM je parallelem Build mit der Engineering-Umgebung in einer Version, die der Adapter kennt
Lizenzen: Lizenzen der Hersteller für Engineering, statische Prüfung und Simulation, je nach Umgebung
Konto: Eigenes Agent-Konto mit Rechten für die Automatisierungsschnittstelle, bei TIA Portal in der Gruppe „Siemens TIA Openness“ und nicht LocalSystem; das Tool ist in der Openness-Firewall freigegeben
Repository: Quellen als Text, Basisprojekt als Archiv in Git LFS

// 08Einordnung

Wo steht das Build Tool
in der Kette?

Die vier Werkzeuge bauen aufeinander auf: versionieren, bauen und testen, nachweisen, mit KI entwickeln. Jedes läuft auch allein, in Ihrer vorhandenen Pipeline. Die ganze Strecke bis zur Anlage deckt die Plattform IndustrialFlow ab.

01 · Versionieren
PLC Git Bridge
02 · Bauen und testen
PLC Build Tool
Diese Seite
03 · Nachweisen
PLC SBOM Builder
04 · Mit KI entwickeln
PLC KI Tool

Plattform · Verfügbar als 90-Tage-Pilot

IndustrialFlow

Entspricht in IndustrialFlow den Pipeline-Stufen Compile und Simulationstest.

// 09Frühe Nutzung

Ab wann geht das
bei uns?

Wir suchen Teams, die eine Pipeline für ihre SPS-Projekte aufbauen und das Build Tool früh auf dem eigenen Build-Agenten einsetzen wollen. Welche Adapter zuerst fertig werden, richtet sich auch nach diesen Teams. Was dafür nötig ist und ab wann es geht, klären wir in einem kurzen Gespräch.

Frühen Zugang anfragen

30 Minuten · unverbindlich · kein Vertriebsgespräch

PLC Build Tool: SPS-Builds in jeder Pipeline

Was ist das PLC Build Tool?

Woran scheitern selbst geschriebene Build-Skripte?

Was soll das Build Toolkönnen?

restore und import

compile

analyze

test

report, archive, cleanup