Comquent GmbH Logo
Kostenlose DevOps-Analyse
00
Zurück zum Blog
CI/CD28. Februar 202616 min Lesezeit

CI/CD für SPS-Entwicklung.
Siemens TIA Portal mit
Jenkins & Claude Code.

Schritt-für-Schritt-Anleitung: So automatisieren Sie Build, Test und Deployment von TIA-Portal-Projekten mit Jenkins, und wie Sie Claude Code per MCP-Server in Engineering und Pipeline einbinden. Inklusive Jenkinsfile-Beispiel und PLCSim-Integration.

CI/CD Pipeline für SPS-Entwicklung mit TIA Portal und JenkinsAI
01
// 01Kurz erklärt

Von Andreas Schönfeld, Geschäftsführer der Comquent GmbH. Er arbeitet seit 2006 mit Jenkins und CI/CD. An der SPS-Entwicklung beschäftigt ihn vor allem der Unterschied im Einsatz: In der klassischen Softwareentwicklung ist ein fehlgeschlagenes Deployment ein Rollback von Sekunden. An der Anlage steht dahinter eine Schicht, die nicht produziert. Eine Pipeline für Steuerungscode muss deshalb nicht schnell sein, sondern belastbar.

Comquent baut diese Pipelines im Kontext Industrial DevOps: TIA-Portal-Projekte, die über die TIA Openness API headless kompiliert werden, Jenkins-Agents unter Windows mit lizenzierter Engineering-Installation, Tests gegen PLCSim Advanced statt gegen die Maschine. Was dabei trägt und was nicht, entsteht in Kundenprojekten und in eigener Erprobung, bis hin zu der Frage, wo KI-Assistenten wie Claude Code im Engineering wirklich helfen.

Der Weg dorthin beginnt selten bei Jenkins: zuerst der textbasierte Export und die Versionsverwaltung mit Git, dann die CI/CD-Implementierung, dann die Ausweitung auf weitere Projekte und Teams. Dazu kommen Workshops, in denen Automatisierungs- und IT-Kollegen am eigenen Projekt üben statt an einem Demo-Beispiel.

Comquent-Team in einer Fertigungshalle vor Werkzeugmaschinen: Automatisierungstechnik und Softwareentwicklung in einem ProjektAI

Stand: 10. September 2026 · Siemens TIA Portal V21 · PLCSim Advanced V6 · Jenkins LTS 2.504 · SIMATIC AX (Early Access) · Claude Code

Siemens TIA Portal (Totally Integrated Automation Portal) ist die Engineering-Software von Siemens zur Programmierung, Simulation und Inbetriebnahme von SIMATIC-SPS, HMI-Panels und Antrieben. CI/CD für SPS-Entwicklung ist möglich: Mit der TIA Openness API lässt sich Siemens TIA Portal headless kompilieren, PLCSim Advanced übernimmt automatisierte Simulationstests, und Jenkins orchestriert alle Stages vom Git-Commit bis zum kontrollierten Deployment. Mit Claude Code kommt KI dazu: Über einen TIA-Portal-MCP-Server generiert es SCL-Bausteine und analysiert Jenkins-Build-Logs. Typisches Ergebnis: 40–60 % kürzere Inbetriebnahmezeit und keine manuellen Übertragungsfehler mehr.

// Kurz gefragt1 Klick, anonym

Ist CI/CD für SPS bei Ihnen gerade ein Thema?

Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.

Warum CI/CD
für die
SPS-Entwicklung.

In der klassischen Software-Entwicklung ist Continuous Integration und Continuous Delivery seit Jahren Standard. Jede Code-Änderung wird automatisch gebaut, getestet und deployt. Weniger Fehler, schnellere Releases. Im Kontext Industrial DevOps überträgt Comquent genau diese Praxis auf SPS- und Embedded-Umgebungen.

In der SPS-Entwicklung sieht die Realität anders aus. Projekte im Siemens TIA Portal werden manuell kompiliert, per USB-Stick verteilt und ohne systematische Tests auf die Anlage übertragen. Versionierung? Oft eine Kopie des Projektordners mit Datum im Namen. Falls Sie sich hier wiedererkennen: Diesen Ordner gibt es in fast jeder Automatisierungsabteilung, und der Weg heraus ist kürzer, als er von hier aus aussieht.

Das muss nicht so bleiben. Mit der TIA Openness API, PLCSim Advanced und Jenkins lässt sich eine vollwertige CI/CD-Pipeline für SPS-Projekte aufbauen. Welche Herausforderungen dabei in der Praxis auftreten, beleuchtet der Anwendungsfall Maschinenbau & SPS/PLC.

Laut dem Accelerate State of DevOps Report 2021 deployen die stärksten Teams 973-mal häufiger als die schwächsten. Diese Zahl stammt aus der klassischen Softwareentwicklung, und niemand deployt 973-mal häufiger auf eine Anlage. Übertragbar ist etwas anderes: In unseren SPS-Projekten liegen die Inbetriebnahmezeiten danach typischerweise 40–60 % niedriger, und manuelle Übertragungsfehler fallen weg. Die offizielle Siemens-Dokumentation beschreibt den Rahmen. Hier zeigen wir, wie er in einem realen Projekt aussieht.

-75 %
Manuelle Deployment-Schritte
-60 %
Fehleridentifikation
100 %
Nachvollziehbarkeit
3x
Release-Häufigkeit

Quelle: Projekterfahrungen Comquent (2006-2026)

02
// 02Architektur-Vergleich

Was unterscheidet
das Siemens TIA Portal
von klassischer Software?

Eine CI/CD-Pipeline für das Siemens TIA Portal durchläuft dieselben Stages wie eine klassische Software-Pipeline, unterscheidet sich aber in vier Punkten: Der Build läuft zwingend unter Windows über die TIA Openness API, getestet wird gegen PLCSim Advanced statt gegen Container, deployt wird im geplanten Wartungsfenster statt jederzeit, und ein Rollback dauert Minuten statt Sekunden.

AspektKlassische SoftwareSPS / TIA Portal
Build-SystemMaven, Gradle, npmTIA Openness API (Headless)
BetriebssystemLinux / Windows / macOSWindows (zwingend)
Test-UmgebungDocker-Container, VMsPLCSim Advanced, SIMIT
DeploymentJederzeit, automatischGeplantes Wartungsfenster
RollbackSekunden (Container)Minuten (SPS-Download)
03
// 03Pipeline-Stages

Sechs Stages.
Vom Commit zur Anlage.

Vom Git-Commit bis zum kontrollierten Deployment: jede Stage mit ihrer Aufgabe und ihrer Toolchain. In den meisten Projekten gibt es dabei einen Moment, der das Team überzeugt: Die Pipeline meldet den ersten Kompilierfehler, bevor jemand zur Anlage gefahren ist.

Wie stark eine solche Pipeline entlastet, hängt weniger an der Branche als an der Zahl der baugleichen Stationen. In der Lagerautomatisierung sind sie der Alltag. Ein Regalbediengerät, zwei Dutzend Förderstrecken und eine Sortieranlage laufen auf S7-1500-Steuerungen, die im Siemens TIA Portal projektiert werden, und über die Jahre driftet die Konfiguration jeder Station leicht auseinander. Die Pipeline kompiliert jede Änderung einmal, testet sie gegen PLCSim Advanced und rollt denselben Stand über die ganze Anlage aus, statt jede Steuerung einzeln von Hand zu pflegen.

  • /01

    Checkout

    Git · TIA Openness API

    SPS-Quellcode aus Git-Repository auschecken. TIA-Portal-Projekte werden als Verzeichnisstruktur oder als exportierte XML-Dateien versioniert.
  • /02

    Build

    TIA Portal V18+ · TIA Openness · Jenkins Agent

    TIA-Portal-Projekt im Headless-Modus kompilieren. Die TIA Openness API ermöglicht automatisierte Builds ohne GUI-Interaktion.
  • /03

    Simulate

    PLCSim Advanced V5+ · SIMIT · Virtual Commissioning

    Kompilierten Code auf PLCSim Advanced laden und gegen virtuelle Anlagenmodelle testen. Hardware-in-the-Loop ohne physische Hardware.
  • /04

    Test

    TIA Test Suite · Custom Scripts · JUnit Reporter

    Automatisierte Funktionstests, Regressionstests und Grenzwerttests ausführen. Testergebnisse werden als JUnit-XML exportiert.
  • /05

    Quality Gate

    Custom Analyzers · IEC 62443 Checks · SonarQube

    Code-Analyse, Namenskonventionen, Sicherheitsregeln und Compliance-Checks prüfen. Bei einem Verstoß stoppt die Pipeline.
  • /06

    Deploy

    Artifactory/Nexus · TIA Openness · Deployment Scripts

    Artefakte in ein Release-Repository überführen. Deployment auf die Ziel-SPS erfolgt kontrolliert im geplanten Wartungsfenster.
// 04Jenkinsfile-Beispiel

Das komplette
Jenkinsfile.

Eine vollständige Pipeline für ein TIA-Portal-Projekt, gedacht als Startpunkt. Pfade, Projektnamen und Qualitätskriterien passen Sie an Ihre Umgebung an.

Jenkinsfile
pipeline {
    agent { label 'windows-tia' }

    environment {
        TIA_VERSION    = 'V18'
        PROJECT_PATH   = 'src/MyPlcProject'
        PLCSIM_TIMEOUT = '300'
    }

    options {
        timeout(time: 60, unit: 'MINUTES')
        timestamps()
        disableConcurrentBuilds()
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
                echo "Projekt ausgecheckt: ${env.GIT_COMMIT}"
            }
        }

        stage('Build') {
            steps {
                powershell '''
                    $tiaPath = "C:\Program Files\Siemens\Automation\Portal ${env:TIA_VERSION}"
                    Import-Module "${tiaPath}\PublicAPI\Siemens.Engineering.dll"

                    $project = [Siemens.Engineering.TiaPortal]::Open(${env:PROJECT_PATH})
                    $project.CompileAll()

                    if ($project.CompileResult.HasErrors) {
                        throw "Build fehlgeschlagen"
                    }
                '''
            }
        }

        stage('Simulate & Test') {
            steps {
                powershell '''
                    Start-PLCSimInstance -Name "TestPLC"
                    Download-ToPlcSim -Project ${env:PROJECT_PATH}
                    Invoke-PlcTests -TestSuite "tests/" -OutputFormat "junit" -OutputPath "test-results/"
                    Stop-PLCSimInstance -Name "TestPLC"
                '''
            }
            post {
                always { junit 'test-results/*.xml' }
            }
        }

        stage('Quality Gate') {
            steps {
                powershell '''
                    Test-NamingConventions -Path ${env:PROJECT_PATH}
                    Test-SecurityCompliance -Standard "IEC62443"
                    Test-UnusedVariables -Path ${env:PROJECT_PATH}
                '''
            }
        }

        stage('Package') {
            steps {
                powershell '''
                    $version = "${env:BUILD_NUMBER}"
                    Compress-Archive -Path ${env:PROJECT_PATH} -DestinationPath "release/MyPlcProject-v${version}.zip"
                '''
                archiveArtifacts artifacts: 'release/*.zip'
            }
        }

        stage('Deploy (Staging)') {
            when { branch 'release/*' }
            steps {
                input message: 'Deployment auf Staging-SPS?', ok: 'Deployen'
                powershell '''
                    Deploy-ToStagingPlc -Package "release/MyPlcProject-*.zip" -Target "192.168.1.100"
                '''
            }
        }
    }

    post {
        success { echo "Pipeline erfolgreich abgeschlossen" }
        failure { echo "Pipeline fehlgeschlagen" }
    }
}
Hinweis

Die PowerShell-Cmdlets sind vereinfacht dargestellt. In der Praxis benötigen Sie Wrapper-Scripts, die die TIA Openness API korrekt ansprechen und Fehlerbehandlung implementieren. Im Rahmen unserer CI/CD-Implementierung stellen wir unseren Kunden erprobte Script-Bibliotheken zur Verfügung.

05
// 05KI-Integration

Was kann Claude Code
im Siemens TIA Portal?

Claude Code greift über einen TIA-Portal-MCP-Server oder die TIA Openness API direkt auf Projekte im Siemens TIA Portal zu: Es generiert SCL-Code aus natürlicher Sprache, konvertiert Kontaktplan-Logik nach SCL, legt Variablentabellen an und dokumentiert Bausteine. In der CI/CD-Pipeline übernimmt es zusätzlich die Analyse fehlgeschlagener Jenkins-Build-Logs und die Generierung von Testfällen für PLCSim Advanced. Voraussetzung ist ein textbasiert nach Git exportiertes Projekt, im Siemens TIA Portal ab V18, aktuell V21. Dazu ein Review durch den Menschen für jeden Vorschlag.

  • /01

    MCP-Server als Brücke

    Ein MCP-Server (Model Context Protocol) macht Projektstruktur, Bausteine und Variablentabellen des TIA Portal für Claude Code lesbar, technisch auf Basis derselben TIA Openness API, die auch unseren Headless-Build antreibt. Kein Copy-Paste über die Zwischenablage, kein Screenshot-Umweg: Die KI arbeitet auf dem echten Projektstand.
  • /02

    SCL generieren & konvertieren

    Aus einer natürlichsprachigen Anforderung entsteht ein SCL-Baustein-Entwurf; bestehende KOP/FUP-Logik lässt sich nach SCL konvertieren und automatisch dokumentieren. Wie KI-Assistenten die Steuerungsentwicklung insgesamt verändern, zeigt unser Artikel KI in der SPS-Programmierung.
  • /03

    Pipeline-Aufgaben in Jenkins

    In der oben gezeigten Pipeline analysiert Claude Code fehlgeschlagene Build-Logs, schlägt Korrekturen vor und generiert Testfälle für PLCSim Advanced. Wie das per MCP-Server konkret aussieht, beschreibt Vibe Coding & MCP für Jenkins.
  • /04

    Grenzen & Review-Pflicht

    KI-generierter Code geht nie ungeprüft auf die Anlage: Review durch den Menschen, PLCSim-Test und die Quality Gates der Pipeline bleiben Pflicht. Fehlersichere Programme (F-CPU) sind ganz ausgenommen. Voraussetzung für den Review ist der textbasierte Export nach Git, wie ihn das Glossar KI in der SPS-Programmierung einordnet. Wo die Grenzen von Claude Code im Industrial DevOps liegen, behandelt ein eigener Artikel. Dort steht auch, warum Claude Code das TIA-Projekt nicht selbst öffnet.
  • /05

    Alternative: Siemens Industrial Copilot

    Siemens bietet mit dem Industrial Copilot einen direkt im TIA Portal integrierten KI-Assistenten. Claude Code arbeitet dagegen tool-unabhängig im Terminal auf dem versionierten Projektstand und deckt zusätzlich die Pipeline-Seite ab. In der Praxis ergänzen sich beide Ansätze.

Hands-on lernen Sie den Umgang mit Claude Code an Jenkins in unseren Workshops Jenkins-Administration mit KI und Jenkins-Pipeline mit KI , beide mit 80 % Praxisanteil. Dauer, Level und Preise stehen nebeneinander in der Übersicht der Jenkins-Schulungen und -Seminare.

06
// 06MCP-Server

Welche MCP-Server gibt es
für das TIA Portal?

Für das Siemens TIA Portal gibt es mehrere MCP-Server, die alle auf derselben TIA Openness API aufsetzen: die VS-Code-Erweiterung vscode-tiaportal-mcp, das Claude-Code-Plugin totally-integrated-claude, der kommerzielle Dienst T-IA Connect für die Versionen V17 bis V21 und die S7 MCP Bridge, die nicht das Engineering, sondern die laufende Steuerung anspricht. Einen von Siemens selbst gepflegten MCP-Server für das TIA Portal gibt es im August 2026 nicht. Siemens hat einen MCP-Server bislang für die WinCC Unified Runtime veröffentlicht, also für die Visualisierung, nicht für das Engineering-Werkzeug.

  • /01

    vscode-tiaportal-mcp

    Open Source, VS-Code-Erweiterung.

    Verbindet sich mit einer laufenden TIA-Portal-Instanz und macht deren Projektbaum im Editor durchsuchbar. Das Projekt von Johannes Heilingbrunner ist das Projekt, auf das die meisten Anleitungen verweisen, und der pragmatische Einstieg, wenn Sie erst einmal sehen wollen, was ein Sprachmodell mit Ihrem Projekt anfängt.
  • /02

    totally-integrated-claude

    Claude-Code-Plugin mit Skill-Routing.

    Kein reiner Server, sondern ein Plugin für Claude Code mit vorgefertigten Skills für wiederkehrende Engineering-Aufgaben. Interessant, weil es die Arbeitsweise vorgibt, statt nur die Schnittstelle zu öffnen.
  • /03

    T-IA Connect

    Kommerziell, V17 bis V21.

    Deckt mit über 120 Werkzeugen den vollen Zyklus ab: Bausteine anlegen, Variablen verwalten, kompilieren, laden, simulieren. Wer eine Zusage zu Support und Versionspflege braucht, landet in der Regel hier. Für einen Proof of Concept ist der Funktionsumfang meist größer als nötig.
  • /04

    S7 MCP Bridge

    Runtime statt Engineering.

    Spricht nicht das Projekt an, sondern die laufende S7-1200 oder S7-1500. Das ist eine andere Risikoklasse. Ein Agent, der Merker in einer produktiven Anlage lesen und schreiben kann, gehört nicht in dieselbe Diskussion wie ein Assistent, der SCL-Entwürfe schreibt. Wir setzen das im Engineering nicht ein.

Was die Anbindung
voraussetzt.

Auf der Engineering-Station brauchen Sie eine lizenzierte TIA-Portal-Installation mit eingerichtetem Openness-Zugriff sowie das .NET Framework 4.8. Die verbreiteten Anleitungen setzen V20 oder V21 voraus, T-IA Connect gibt V17 bis V21 an. Unser Headless-Build läuft ab V18 stabil. Prüfen Sie deshalb beides: ob Ihre Version Openness kann und welche Version der jeweilige Server erwartet.

Eine Kleinigkeit steht in keiner Anleitung und entscheidet trotzdem über den Verbindungsaufbau: Der Windows-Benutzer, unter dem der Server läuft, muss in der lokalen Gruppe Siemens TIA Openness stehen. Fehlt der Eintrag, meldet das Portal einen wenig hilfreichen Zugriffsfehler.

Die eigentliche Voraussetzung ist am Ende keine technische. Solange das Projekt als .zap-Datei auf dem Netzlaufwerk liegt, sehen Sie zwar, was die KI vorschlägt, aber nicht, was sie verändert hat. Der textbasierte Export nach Git kommt zuerst, der MCP-Server danach.

Bleibt die Frage, die in regulierten Umgebungen zuerst kommt: Was darf so ein Server eigentlich? Unsere Antwort aus den Projekten ist unspektakulär. Lesend auf die laufende Instanz, schreibend ausschließlich in die Git-Arbeitskopie, Übernahme über einen Merge Request mit menschlichem Review. Damit bleibt jede KI-Änderung ein nachvollziehbarer Commit, und die Frage nach der Freigabe beantwortet die Historie statt eines Protokolls. Wie sich das in ein Sicherheitskonzept nach IEC 62443 einfügt, ordnet unsere DevSecOps-Beratung ein.

// 07Voraussetzungen

Was Sie
brauchen.

  • /01

    TIA Portal V18 oder höher

    Ohne V18 kein stabiler Headless-Build.

    Ältere Versionen unterstützen TIA Openness nur eingeschränkt. Ab V18 ist Headless-Build zuverlässig möglich.
  • /02

    Jenkins-Server mit Windows-Agent

    TIA Portal läuft nur unter Windows.

    Der Jenkins-Agent benötigt eine lizenzierte TIA-Portal-Installation. Floating Licenses empfohlen.
  • /03

    PLCSim Advanced V5+

    Für automatisierte Simulation und Tests.

    Die Advanced-Variante unterstützt API-Zugriff und mehrere Instanzen parallel.
  • /04

    Git-Repository

    Projekte als Verzeichnisstruktur speichern.

    TIA-Portal-Projekte müssen als Verzeichnisstruktur (nicht als einzelne .zap-Datei) gespeichert werden, um diff-fähig zu sein.
  • /05

    Netzwerkzugang

    Zugriff auf Repository und SPS.

    Der Jenkins-Agent muss Zugriff auf das Git-Repository und optional auf die Ziel-SPS oder ein Staging-System haben.
08
// 08Git-Strategie

Projektstruktur
und Branching.

Die Versionierung von SPS-Projekten in Git ist der erste und wichtigste Schritt. Ohne saubere Versionskontrolle ist CI/CD nicht möglich. Wie Sie TIA Portal mit Git versionieren, über das Version Control Interface (VCI) oder über Openness, zeigt unser Schritt-für-Schritt-Leitfaden; einen herstellerübergreifenden Einblick bietet der Artikel zur SPS-Versionsverwaltung mit Git.

my-plc-project/
my-plc-project/
├── src/
│   ├── PLC_1/              # SPS-Programm
│   ├── HMI_1/              # HMI-Projekt
│   └── Safety/             # Safety-Programm
├── tests/
│   ├── unit/               # FB-Unit-Tests
│   └── integration/        # PLCSim-Tests
├── scripts/
│   ├── build.ps1           # Build-Script
│   ├── test.ps1            # Test-Script
│   └── deploy.ps1          # Deploy-Script
├── Jenkinsfile             # Pipeline-Definition
├── .gitignore              # Binaries ausschliessen
└── .gitattributes          # LFS für große Dateien

Branching-
Modell.

  • mainProduktionsreifer Code, nur über Merge-Requests
  • developIntegrations-Branch für laufende Entwicklung
  • feature/*Feature-Branches für neue Funktionsbausteine
  • release/*Release-Kandidaten für geplante Wartungsfenster
  • hotfix/*Dringende Korrekturen für Produktionsanlagen
09
// 09Fallstricke

Fünf Stolperstellen.
Und wie Sie sie vermeiden.

Aus über 100 Projekten kennen wir die häufigsten Stolperstellen bei der CI/CD-Einführung für SPS-Entwicklung.

  • /01

    Binäre Projektdateien

    Problem

    TIA-Portal speichert standardmäßig binäre .zap-Dateien, die nicht diff-fähig sind. Ändern zwei Kollegen parallel denselben Baustein, gewinnt beim Zusammenführen einer von beiden. Die Arbeit des anderen ist verloren, oft ohne dass es jemand sofort bemerkt.

    Lösung

    Projekte als Verzeichnisstruktur speichern und die TIA Openness API für XML-Export nutzen. So werden Änderungen in Git nachvollziehbar.

  • /02

    Lizenzverwaltung

    Problem

    Jeder Jenkins-Agent benötigt eine eigene TIA-Portal-Lizenz. Bei mehreren parallelen Builds steigen die Kosten.

    Lösung

    Floating Licenses nutzen und die Anzahl paralleler Builds begrenzen. Alternativ: einen dedizierten Build-Agent mit Exklusiv-Lizenz einsetzen.

  • /03

    Lange Build-Zeiten

    Problem

    TIA-Portal-Kompilierung kann bei großen Projekten 10-30 Minuten dauern.

    Lösung

    Inkrementelle Builds nutzen, nur geänderte Bausteine kompilieren und Build-Caching implementieren. Nightly Full-Builds für Sicherheit.

  • /04

    Testabdeckung

    Problem

    Automatisierte Tests für SPS-Code sind deutlich schwieriger als für klassische Software.

    Lösung

    Mit Unit-Tests für Funktionsbausteine (FBs) starten, dann schrittweise Integrationstests mit PLCSim Advanced aufbauen. 60-70 % der kritischen Pfade reichen für den Anfang.

  • /05

    Team-Akzeptanz

    Problem

    SPS-Programmierer sind oft nicht mit Git und CI/CD vertraut. Widerstand gegen neue Workflows.

    Lösung

    Früh einbinden, den Nutzen zeigen („nie wieder verlorene Änderungen“), Schulungen anbieten und mit einem Pilotprojekt starten.

Berater erläutert am Monitor eine CI/CD-Pipeline mit Build- und Teststufen, daneben ein Schaltschrank mit SPSAI
// Workshop · Admin

Jenkins-Administration mit KI

Plugin-Konflikte, JCasC, CIS-Hardening, Build-Log-Analyse. 2 Tage, 80 % Hands-on, mit Claude Code im Terminal.

Workshop ansehen
// Workshop · Pipeline

Jenkins-Pipeline mit KI

CPS-Fehler, Shared Libraries, JenkinsPipelineUnit, Pipeline-Refactoring. 2 Tage Pair-Programming mit Claude Code.

Workshop ansehen
// 10SIMATIC AX

Und was ist mit
SIMATIC AX?

SIMATIC AX ist der textbasierte Engineering-Weg, den Siemens selbst für SIMATIC-Steuerungen anbietet: eine Entwicklungsumgebung auf Basis von Visual Studio Code, die Siemens als IT-like way of engineering PLCs beschreibt und die Git-Versionierung, Paketverwaltung, Unit-Tests und CI-Pipelines von Haus aus mitbringt. AX löst damit genau das Problem, um das der Rest dieses Artikels herumbaut: Der Projektstand ist von Anfang an Text und braucht keinen Export. Siemens führt AX derzeit als Early Access für ausgewählte produktive Anwendungsfälle. Das TIA Portal ersetzt es damit noch nicht.

  • /01

    Was AX mitbringt

    Werkzeuge, die man aus der Softwareentwicklung kennt.

    Strukturierter Text in VS Code, Pakete über apax, Unit-Tests über AxUnit, native Git-Anbindung. Ein AX-Projekt lässt sich ohne Zwischenschritt in Jenkins bauen und testen. Die Stages aus Abschnitt 03 bleiben dieselben, nur Checkout und Build werden einfacher, weil kein Openness-Wrapper mehr dazwischensteht.
  • /02

    Was AX nicht löst

    Ihr Bestand bleibt, wo er ist.

    Die Anlagen, die heute in Betrieb sind, laufen auf TIA-Portal-Projekten, und dafür gibt es keinen Umstiegsknopf. Wer eine Flotte gewachsener Projekte betreut, bekommt mit AX zunächst eine zweite Toolchain neben der ersten. Das kann sinnvoll sein, ist aber eine Entscheidung über Jahre, nicht über ein Quartal.
  • /03

    Welcher Weg wann

    Die Frage ist Greenfield oder Brownfield.

    Bei einer neuen Maschinenbaureihe, die ohnehin von vorn entsteht, lohnt der Blick auf AX vor der ersten Zeile Code. Bei einer bestehenden Anlagenlandschaft ist die in diesem Artikel beschriebene Pipeline über Openness und PLCSim der realistische Weg, und zwar unabhängig davon, was Siemens in zwei Jahren ausliefert. Beide Wege enden im selben Jenkins.

Wenn Sie an dieser Stelle noch nichts entscheiden, sondern erst einmal wissen wollen, wo Ihr Team steht, ist das der übliche Stand. Der DevOps-Reifegrad-Check fragt 15 Minuten lang genau die Stellen ab, an denen SPS-Pipelines scheitern, und sagt Ihnen, wo Sie zuerst ansetzen sollten. Ohne Termin, ohne Angebot. Wer lieber über den konkreten Fall spricht, bekommt im kostenlosen Erstgespräch 30 Minuten mit jemandem, der solche Pipelines gebaut hat. Und wenn dabei herauskommt, dass sich der Aufwand bei zwei Programmierern und einem Projekt nicht lohnt, sagen wir das auch.

// 11Andere Hersteller

Über Siemens hinaus.
CODESYS, Beckhoff, Rockwell.

Die beschriebenen Prinzipien sind herstellerübergreifend anwendbar. Die Implementierung unterscheidet sich je nach Toolchain. Das Grundkonzept aus Versionierung, Build, Simulation und Quality Gates bleibt identisch.

  • /01

    CODESYS

    CODESYS bietet mit dem CODESYS Automation Server eine eigene CI/CD-Lösung. Alternativ lässt sich die CODESYS-Kommandozeile in Jenkins-Pipelines integrieren. Die Projekte sind textbasiert und dadurch nativ git-freundlich.
  • /02

    Beckhoff TwinCAT

    TwinCAT-Projekte basieren auf Visual Studio und lassen sich über MSBuild automatisiert kompilieren. Die Integration in Jenkins oder Azure DevOps ist geradlinig. Tests über TwinCAT-Simulation oder TcUnit.
  • /03

    Rockwell Studio 5000

    Rockwell bietet mit FactoryTalk Logix Echo eine Emulations-Umgebung ähnlich PLCSim Advanced. Die Kommandozeilensteuerung ist eingeschränkter als bei Siemens, aber über die Logix Designer SDK lassen sich Builds und Deployments automatisieren.

Unabhängig vom Hersteller gilt: Der Industrial-DevOps-Ansatz ist die strategische Klammer. Die Wahl des SPS-Herstellers bestimmt die Werkzeuge, nicht das Prinzip. Welcher SPS-Hersteller welches Tool nutzt und wie git-tauglich es ist, zeigt der herstellerübergreifende Vergleich. Für die Compliance-Anforderungen des Cyber Resilience Act ist eine nachvollziehbare, automatisierte Build-Pipeline künftig ohnehin Pflicht. Wer erst dann anfängt, Änderungshistorien zu rekonstruieren, diskutiert mit dem Auditor über Lücken statt über Ergebnisse. Die Pipeline liefert den Nachweis nebenbei.

// 12Häufige Fragen

Was Kunden
wirklich fragen.

Q.01
Was ist Siemens TIA Portal?
Das Siemens TIA Portal (Totally Integrated Automation Portal) ist die zentrale Engineering-Software von Siemens für die Automatisierungstechnik. Damit werden SIMATIC-SPS (S7-1200/S7-1500), HMI-Panels und Antriebe in einer gemeinsamen Oberfläche projektiert, in Sprachen wie SCL, KOP und FUP programmiert und in Betrieb genommen. Über die TIA Openness API lässt sich das Portal skripten und headless in eine CI/CD-Pipeline einbinden.
Q.02
Kann man SPS-Programmierung mit CI/CD automatisieren?
Ja, SPS-Projekte wie Siemens TIA-Portal lassen sich vollständig in CI/CD-Pipelines integrieren, inklusive automatisiertem Build, Simulation mit PLCSim und Quality Gates. Die Automatisierung nimmt manuelle Fehlerquellen heraus und verkürzt den Weg vom Commit zur getesteten Version.
Q.03
Welche CI/CD-Tools eignen sich für TIA-Portal-Projekte?
Jenkins ist der am häufigsten eingesetzte CI/CD-Server für SPS-Automatisierung, da er über Plugins und Kommandozeilenaufrufe flexibel an TIA-Portal angebunden werden kann. Auch GitLab CI und Azure DevOps sind grundsätzlich geeignet, erfordern aber Custom-Skripte für die Siemens-Toolchain.
Q.04
Wie versioniert man Steuerungscode mit Git?
TIA-Portal-Projekte werden als exportierte Dateien in ein Git-Repository eingecheckt, wobei die Projektstruktur in sinnvolle Verzeichnisse aufgeteilt wird. Mit .gitignore-Regeln schließen Sie temporäre und generierte Dateien aus, sodass nur der Steuerungscode im Repository landet.
Q.05
Was ist PLCSim Advanced und wie wird es in CI/CD genutzt?
PLCSim Advanced ist eine Software-Simulation von Siemens, die eine virtuelle SPS bereitstellt und sich per API steuern lässt. In der CI/CD-Pipeline wird PLCSim Advanced gestartet, das kompilierte Programm geladen und automatisierte Tests gegen die Simulation ausgeführt.
Q.06
Wie lange dauert die Einführung von CI/CD für SPS-Entwicklung?
Ein Proof of Concept mit einer funktionsfähigen Pipeline für ein Pilotprojekt lässt sich in zwei Wochen aufsetzen. Die Skalierung auf weitere Projekte und Teams dauert typischerweise drei bis sechs Monate.
Q.07
Welche Vorteile bringt CI/CD in der SPS-Entwicklung?
Typische Ergebnisse sind eine Reduzierung der Inbetriebnahmezeit um 40–60 %, der Wegfall manueller Übertragungsfehler und eine lückenlose Nachverfolgbarkeit aller Änderungen am Steuerungscode. Dazu kommt, dass mehrere Entwickler parallel am selben Projekt arbeiten können.
Q.08
Eignet sich CI/CD für die Lagerautomatisierung mit dem TIA Portal?
Ja, besonders dort. Lageranlagen bestehen meist aus vielen baugleichen Stationen wie Regalbediengeräten, Förderstrecken und Sortierern, die im Siemens TIA Portal auf S7-1500-Steuerungen laufen. Eine CI/CD-Pipeline kompiliert jede Änderung einmal, prüft sie gegen PLCSim Advanced und rollt denselben Stand über alle Stationen aus, statt jede Steuerung einzeln von Hand zu pflegen. So bleibt die Konfiguration über die gesamte Anlage konsistent und jede Änderung nachvollziehbar.
Q.09
Funktioniert CI/CD auch mit anderen SPS-Herstellern als Siemens?
Ja, das Grundprinzip ist herstellerübergreifend anwendbar. Die konkrete Implementierung unterscheidet sich je nach Toolchain. Für CODESYS, Beckhoff TwinCAT und Rockwell Studio 5000 gibt es ebenfalls Wege, den Build über die Kommandozeile anzustoßen und in eine Pipeline zu hängen.
Q.10
Was sind Quality Gates in einer SPS-CI/CD-Pipeline?
Quality Gates sind automatisierte Prüfpunkte, die bestimmte Qualitätskriterien erzwingen, bevor der Code die nächste Pipeline-Stage erreicht. Typische Gates für SPS-Code umfassen Kompilierungserfolg, Simulationstests, Code-Analyse und Dokumentationsvollständigkeit.
Q.11
Kann Claude Code mit Siemens TIA Portal arbeiten?
Ja. Über einen TIA-Portal-MCP-Server oder die TIA Openness API greift Claude Code direkt auf TIA-Portal-Projekte zu: Es generiert SCL-Code, konvertiert Kontaktplan-Logik nach SCL, legt Variablentabellen an und dokumentiert Bausteine. Voraussetzung ist ein textbasiert exportiertes, in Git versioniertes Projekt. Nur dann bleibt jeder KI-Vorschlag reviewbar.
Q.12
Welche MCP-Server gibt es für das Siemens TIA Portal?
Für das TIA Portal existieren mehrere MCP-Server, die alle auf der TIA Openness API aufsetzen: die Open-Source-Erweiterung vscode-tiaportal-mcp für Visual Studio Code, das Claude-Code-Plugin totally-integrated-claude, der kommerzielle Dienst T-IA Connect für die Versionen V17 bis V21 sowie die S7 MCP Bridge, die nicht das Engineering-Projekt, sondern die laufende S7-Steuerung anspricht. Einen von Siemens selbst gepflegten MCP-Server für das TIA Portal gibt es im August 2026 nicht; veröffentlicht hat Siemens bislang einen MCP-Server für die WinCC Unified Runtime.
Q.13
Was braucht Claude Code, um sich mit dem TIA Portal zu verbinden?
Nötig sind eine lizenzierte TIA-Portal-Installation mit eingerichtetem Openness-Zugriff, das .NET Framework 4.8 und ein MCP-Server, der zur installierten Version passt. Die verbreiteten Anleitungen setzen V20 oder V21 voraus, während einzelne Server ab V17 arbeiten. Der ausführende Windows-Benutzer muss zusätzlich Mitglied der lokalen Benutzergruppe Siemens TIA Openness sein, sonst scheitert der Verbindungsaufbau mit einem Zugriffsfehler. Sinnvoll wird die Anbindung erst mit einem textbasiert exportierten, in Git versionierten Projekt, weil sich nur dann nachvollziehen lässt, was die KI verändert hat.
Q.14
Was ist SIMATIC AX und ersetzt es die CI/CD-Pipeline für das TIA Portal?
SIMATIC AX ist die textbasierte Engineering-Umgebung von Siemens auf Basis von Visual Studio Code, die Git-Versionierung, Paketverwaltung über apax, Unit-Tests über AxUnit und CI-Pipelines von Haus aus mitbringt. Sie ersetzt die hier beschriebene Pipeline nicht, sondern vereinfacht deren Anfang: Ein AX-Projekt ist von Beginn an Text und braucht keinen Openness-Export. Siemens führt SIMATIC AX derzeit als Early Access für ausgewählte produktive Anwendungsfälle. Für bestehende TIA-Portal-Projekte bleibt der Weg über Openness und PLCSim Advanced der realistische, für eine neue Maschinenbaureihe lohnt der Blick auf AX vor der ersten Zeile Code.
Q.15
Wie kompiliert man ein TIA-Portal-Projekt ohne die Oberfläche?
Über die TIA Openness API: Ein Skript öffnet das Projekt im Hintergrund, stößt die Kompilierung der Bausteine an und liest das Ergebnis samt Fehlerliste aus. In der Praxis läuft das als PowerShell- oder C#-Wrapper auf einem Windows-Jenkins-Agent mit lizenzierter TIA-Portal-Installation. Eine reine Kommandozeile ohne installiertes TIA Portal gibt es nicht, die Lizenz bleibt also auch im automatisierten Build erforderlich.
Q.16
Was ist der TIA Portal MCP Server?
Ein MCP-Server (Model Context Protocol) verbindet KI-Assistenten wie Claude Code mit dem Siemens TIA Portal. Er nutzt die TIA Openness API, um Projektstruktur, Bausteine und Variablentabellen für die KI lesbar zu machen. Claude Code generiert damit SCL und analysiert Projekte, ohne Copy-Paste über die Zwischenablage.
Q.17
Worin unterscheiden sich Claude Code und der Siemens Industrial Copilot?
Der Siemens Industrial Copilot ist direkt in das TIA Portal integriert und generiert dort SCL aus natürlicher Sprache. Claude Code arbeitet tool-unabhängig im Terminal auf dem versionierten Projektstand und kombiniert SCL-Generierung mit Pipeline-Aufgaben wie Jenkins-Build-Log-Analyse und Testfall-Erstellung. In der Praxis ergänzen sich beide Ansätze.
// +Weiterlesen
TIA Portal mit Git versionierenIndustrial DevOps LeitfadenJenkins vs. GitLab vs. AzureSPS Versionsverwaltung
// Ihr nächster Schritt1 Klick, anonym

Wie geht es bei Ihnen mit CI/CD für SPS weiter?

Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.

// 13 — Einstiegsangebot

2 Wochen.
4.900 EUR.
SPS-Pipeline.

Proof of Concept zum Festpreis: Wir setzen in 2 Wochen eine funktionierende CI/CD-Pipeline für Ihr TIA-Portal-Projekt auf. Build, Test und Quality Gates inklusive. Noch nicht sicher, ob Ihr Projekt reif dafür ist? Ein 30-minütiges Erstgespräch klärt das vorab, kostenlos und ohne Verpflichtung.

PoC anfragen
Festpreis · 2 Wochen
Inkl. Dokumentation

Verwandte Artikel

SPS / PLC

TIA Portal mit Git versionieren: VCI, Openness & CI/CD

Die Git-Grundlage jeder SPS-Pipeline: TIA-Portal-Code über VCI oder Openness versionieren.

14 Min.Lesen
Industrial DevOps

Industrial DevOps: Der komplette Leitfaden

Was ist Industrial DevOps? CI/CD für cyber-physische Systeme und Industrie 4.0.

15 Min.Lesen
CI/CD

Jenkins vs. GitLab CI vs. Azure DevOps

CI/CD-Plattform-Vergleich 2026: Stärken, Schwächen und Migrationspfade.

14 Min.Lesen
CI/CD

Vibe Coding & MCP für Jenkins: KI-Pipelines

Jenkins per MCP-Server mit KI steuern, Pipelines vibecoden und Build-Logs per LLM analysieren.

16 Min.Lesen
KI

Claude Code im Industrial DevOps: Grenzen & DSGVO

Wo Claude Code im Industrial DevOps trägt, warum es das TIA-Projekt nicht öffnet und welche Deployment-Variante die DSGVO zulässt.

15 Min.Lesen
// Nächster Schritt

Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.

Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen
Seit 2006 · 47+ Projekte
Industrie · Automotive · Finance