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, Studio 5000 und B&R Automation Studio. 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.

Pilot anfragen Whitepaper CI/CD mit TIA Portal

30 Minuten · unverbindlich · kein Vertriebsgespräch

IN ENTWICKLUNG · EIN BEFEHLSSATZ · FÜNF 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, für B&R Automation Studio das Kommandozeilenwerkzeug BR.AS.Build.exe. 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, B&R Automation Studio
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.

Aufbau · Komponenten im Überblick

Wie ist das PLC Build Tool aufgebaut?

Aus einem Kern, der Befehle, Zeitlimits und Berichte für alle Umgebungen gleich behandelt, und je Engineering-Umgebung einem Adapter, der als eigener Prozess läuft. An die Pipeline gehen Exit-Code, JUnit-XML, SARIF und ein Build-Manifest zurück.

Ihre Infrastruktur

CI-Server: Jenkins, GitLab CI oder Azure DevOps

Orchestriert die Pipeline und startet jeden Schritt auf einem Windows-Agenten als Aufruf von plc-build.

bat "plc-build compile --project linie-1/plc"

git

Ihr Repository

plc.yml: Projekte, Adapter und Einstellungen; dieselbe Datei liest die Git Bridge
Quellen: Bausteine als Text, etwa SIMATIC SD, L5X oder Structured Text
Basisprojekt: Archiv der Umgebung in Git LFS, mit Hardware und Variablentabellen
rules/ · tests/: Regelwerk der statischen Prüfung und Testfälle

Windows-Build-Agent · eine VM je parallelem Build

plc-build

Kern

.NET 10, ohne Herstellernamen im Code. Ein neuer Adapter braucht keine Änderung am Kern.

/01
Befehle
doctor, restore, import, compile, analyze, test, report, archive, cleanup; run fasst mehrere Schritte in einer Sitzung zusammen.
/02
Konfiguration
Liest plc.yml, ordnet jedem Projekt Adapter und Einstellungen zu und prüft, ob Basisprojekt und Quellen da sind. Sonst Exit 2.
/03
Adapter-Start
Findet den Adapter über seine Beschreibung adapter.json, startet ihn als eigenen Prozess und beendet ihn nach dem Zeitlimit.
/04
Ergebnismodell
Prüft Protokollversion und Antwort. Fehlt sie oder ist sie kaputt, wird daraus ein Abbruch, nie ein grüner Build.
/05
Berichte
Schreibt JUnit-XML, SARIF 2.1.0 und das Build-Manifest, sortiert und reproduzierbar.
/06
Prozessbuchführung
Merkt sich PID und Startzeit jedes gestarteten Prozesses. cleanup beendet nur diese, auch nach einem Abbruch.

adapter: tia-v21
C#, .NET Framework 4.8, TIA Portal Openness V21. Je TIA-Version ein eigener Adapter.
ohne Oberfläche
Umgebung
Siemens TIA Portal V21
- TIA Portal V21
- Test Suite: Style Guide Checker, Application Test
- S7-PLCSIM Advanced
adapter: codesys
IronPython 2.7 in CODESYS.exe, Scripting-Schnittstelle mit --noUI
ohne Oberfläche
Umgebung
CODESYS V3.5
- CODESYS Professional Developer Edition
- Static Analysis, Test Manager
- CODESYS Control Win
adapter: twincat
C# über COM, TwinCAT Automation Interface
ohne Oberfläche
Umgebung
Beckhoff TwinCAT 3
- TwinCAT 3 XAE
- TwinCAT 3 PLC Static Analysis
- TcUnit auf der Usermode Runtime
adapter: studio5000
Logix Designer SDK ab V37, L5X-Werkzeuge von Rockwell
ohne Oberfläche
Umgebung
Rockwell Studio 5000
- Studio 5000 Logix Designer
- FactoryTalk Logix Echo
adapter: automation-studio
BR.AS.Build.exe je Konfiguration, Rückgabewerte 0, 1 und 3
ohne Oberfläche
Umgebung
B&R Automation Studio 6
- Automation Studio 6
- Technology Solution UnitTest
- ARsim

+ adapter: eigener · Weitere Umgebungen über eigene Adapter, etwa auf Basis von PLCopen XML

adapter: fake · Testadapter, spielt Fehler, fehlende Lizenz und Hänger durch, damit der Kern ohne Herstellersoftware geprüft wird

out/

Ergebnis an die Pipeline

Exit 0: erfolgreich
Exit 1: Befund im Projekt, der Entwickler ist dran
Exit 2: Aufruf oder plc.yml falsch
Exit 3: Umgebung: Lizenz, Konto, Firewall
Exit 4: Abbruch: Zeitlimit, Absturz

JUnit-XML: Übersetzung, Prüfung und Tests für Jenkins, GitLab CI und Azure DevOps
SARIF 2.1.0: Übersetzungs- und Prüfbefunde mit Objektpfad
Manifest: Commit, Adapter, Werkzeugversionen, Prüfsummen von Basisprojekt und Quellen
Archiv: Gebauter Stand im Archivformat der Umgebung

Oberfläche

Zeigt Builds, die Diagnose von doctor und die Messungen aus denselben Ausgaben, siehe die Ansichten oben.

Nicht Teil des Werkzeugs

Reale Steuerungen. Das Laden auf die Anlage bleibt ein freigegebener Schritt außerhalb des Build Tools.

Komponentenübersicht nach dem Entwicklungsstand Oktober 2026: Kern, Protokoll und Testadapter laufen, die Herstelleradapter sind in Arbeit. Welche zuerst fertig werden, ist offen; Namen und Schnittstellen können sich bis zur ersten Version ändern.

// 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 und B&R Automation Studio 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, die Technology Solution UnitTest auf B&R ARsim 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 fünf 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.
B&R Automation Studio 6	Übersetzt über BR.AS.Build.exe, das Kommandozeilenwerkzeug, das B&R für den Build ohne Oberfläche dokumentiert, je Konfiguration des Projekts. Dessen Rückgabewerte 0, 1 und 3 für fehlerfrei, nur Warnungen und Fehler setzt der Adapter in die Exit-Codes des Build Tools um. Getestet wird mit der Technology Solution UnitTest auf ARsim, der Simulation der Automation Runtime; die Berichte kommen dort schon als JUnit. Die Testfälle schreibt man in C, der geprüfte Baustein darf in jeder Sprache sein. Statische Prüfung bietet B&R bisher nur für C und C++ über clang-tidy, für Structured Text ist sie angekündigt. Automation Studio und ARsim laufen nur unter Windows. Den Weg zu Jenkins hat B&R mit dem DevOps Package selbst beschrieben.

// 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.

Pilot anfragen

30 Minuten · unverbindlich · kein Vertriebsgespräch

PLC Build Tool: SPS-Builds in jeder Pipeline

Was ist das PLC Build Tool?

Wie ist das PLC Build Tool aufgebaut?

Woran scheitern selbst geschriebene Build-Skripte?

Was soll das Build Toolkönnen?

restore und import

compile

analyze

test

report, archive, cleanup