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 reduziert manuelle Fehler und beschleunigt den Release-Zyklus erheblich.

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.

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. Durch .gitignore-Regeln werden temporäre und generierte Dateien ausgeschlossen.

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 ausgeführt.

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.

Funktioniert CI/CD auch mit anderen SPS-Herstellern als Siemens?

Ja, das Grundprinzip ist herstellerübergreifend anwendbar. Für CODESYS, Beckhoff TwinCAT und Rockwell Studio 5000 existieren ebenfalls Ansätze zur Kommandozeilensteuerung und Pipeline-Integration.

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 umfassen Kompilierungserfolg, Simulationstests, Code-Analyse und Dokumentationsvollständigkeit.

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 kann damit SCL generieren und Projekte analysieren, ohne Copy-Paste über die Zwischenablage.

Claude Code oder Siemens Industrial Copilot — was ist der Unterschied?

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.

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 binden Claude Code per MCP-Server in Engineering und Pipeline ein. Inklusive Jenkinsfile-Beispiel und PLCSim-Integration.

CI/CD Pipeline für SPS-Entwicklung mit TIA Portal und Jenkins

// 01Kurz erklärt

Andreas Schönfeld

Geschäftsführer & DevOps-Berater, Comquent GmbH

18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation

Veröffentlicht: 28. Februar 2026Zuletzt aktualisiert: 14. Juli 2026

Stand: Juli 2026 · TIA Portal V21 · PLCSim Advanced V6 · Jenkins LTS 2.504 · Claude Code

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?

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 Realitaet 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: So startet fast jedes Automatisierungsteam, das wir kennenlernen — der Weg heraus ist kürzer, als die meisten erwarten.

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 State of DevOps Report erzielen Unternehmen mit ausgereiften CI/CD-Pipelines 2.000-fach häufigere Deployments. Auch in der SPS-Entwicklung sind die Ergebnisse messbar: typischerweise 40-60 % kuerzere Inbetriebnahmezeiten und die Eliminierung manueller Übertragungsfehler. Die offizielle Siemens-Dokumentation beschreibt den Rahmen — hier zeigen wir die praxiserprobte Umsetzung.

-75 %

Manuelle Deployment-Schritte

-60 %

Fehleridentifikation

100 %

Nachvollziehbarkeit

Release-Häufigkeit

Quelle: Projekterfahrungen Comquent (2006-2026)

// 02Architektur-Vergleich

Klassische Software
vs. Siemens TIA Portal.

Die CI/CD-Pipeline für SPS-Entwicklung unterscheidet sich in einigen Punkten grundlegend von klassischen Software-Pipelines.

Aspekt	Klassische Software	SPS / TIA Portal
Build-System	Maven, Gradle, npm	TIA Openness API (Headless)
Betriebssystem	Linux / Windows / macOS	Windows (zwingend)
Test-Umgebung	Docker-Container, VMs	PLCSim Advanced, SIMIT
Deployment	Jederzeit, automatisch	Geplantes Wartungsfenster
Rollback	Sekunden (Container)	Minuten (SPS-Download)

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

/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 Verstoss wird die Pipeline gestoppt.
/06
Deploy
Artifactory/Nexus · TIA Openness · Deployment Scripts
Artefakte in ein Release-Repository ueberfü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. Startpunkt — passen Sie Pfade, Projektnamen und Qualitätskriterien 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 Verfuegung.

// 05KI-Integration

Was kann Claude Code
im TIA Portal?

Claude Code greift über einen TIA-Portal-MCP-Server oder die TIA Openness API direkt auf Siemens-TIA-Portal-Projekte 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 Build-Log-Analyse und Testfall-Generierung — reviewt wird jeder Vorschlag vom Menschen.

/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) bleiben ganz ausgenommen. Voraussetzung für den Review ist der textbasierte Export nach Git, wie ihn das Glossar KI in der SPS-Programmierung einordnet.
/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.

// 06Voraussetzungen

Was Sie
brauchen.

/01
TIA Portal V18 oder hoeher
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.

// 07Git-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 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

// 08Fallstricke

Fuenf 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
Binaere 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
Frueh einbinden, Vorteile demonstrieren ("nie wieder verlorene Änderungen"), Schulungen anbieten und mit einem Pilot-Projekt starten.

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

// 09Andere Hersteller

Über Siemens hinaus.
CODESYS, Beckhoff, Rockwell.

Die beschriebenen Prinzipien sind herstelleruebergreifend anwendbar. Die Implementierung unterscheidet sich je nach Toolchain, aber Grundkonzept — Versionierung, Build, Simulation, 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.

Unabhaengig 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 kuenftig 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.

// 10Häufige Fragen

Was Kunden
wirklich fragen.

Q.01
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 reduziert manuelle Fehler und beschleunigt den Release-Zyklus erheblich.
Q.02
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.03
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. Durch .gitignore-Regeln werden temporaere und generierte Dateien ausgeschlossen, sodass nur der relevante Steuerungscode versioniert wird.
Q.04
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.05
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.06
Welche Vorteile bringt CI/CD in der SPS-Entwicklung?: Typische Ergebnisse sind eine Reduzierung der Inbetriebnahmezeit um 40-60 %, die Eliminierung manueller Übertragungsfehler und eine lueckenlose Nachverfolgbarkeit aller Änderungen am Steuerungscode. Zusaetzlich ermöglicht die Automatisierung paralleles Arbeiten mehrerer Entwickler am selben Projekt.
Q.07
Funktioniert CI/CD auch mit anderen SPS-Herstellern als Siemens?: Ja, das Grundprinzip ist herstelleruebergreifend anwendbar — die konkrete Implementierung unterscheidet sich jedoch je nach Toolchain. Für CODESYS, Beckhoff TwinCAT und Rockwell Studio 5000 existieren ebenfalls Ansaetze zur Kommandozeilensteuerung und Pipeline-Integration.
Q.08
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.09
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 — so bleibt jeder KI-Vorschlag reviewbar.
Q.10
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 kann damit SCL generieren und Projekte analysieren, ohne Copy-Paste über die Zwischenablage.
Q.11
Claude Code oder Siemens Industrial Copilot — was ist der Unterschied?: 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 versionieren Industrial DevOps Leitfaden Jenkins vs. GitLab vs. Azure SPS Versionsverwaltung

// Ihr nächster Schritt1 Klick, anonym

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

// 11 — 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

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

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

Warum CI/CDfür dieSPS-Entwicklung.

Klassische Softwarevs. Siemens TIA Portal.

Sechs Stages.Vom Commit zur Anlage.

Checkout

Build

Simulate

Test

Quality Gate

Deploy

Das kompletteJenkinsfile.

Was kann Claude Codeim TIA Portal?

MCP-Server als Brücke

SCL generieren & konvertieren

Pipeline-Aufgaben in Jenkins

Grenzen & Review-Pflicht

Alternative: Siemens Industrial Copilot

Was Siebrauchen.

TIA Portal V18 oder hoeher

Jenkins-Server mit Windows-Agent

PLCSim Advanced V5+

Git-Repository

Netzwerkzugang

Projektstrukturund Branching.

Branching-Modell.

Fuenf Stolperstellen.Und wie Sie sie vermeiden.

Binaere Projektdateien

Lizenzverwaltung

Lange Build-Zeiten

Testabdeckung

Team-Akzeptanz

Jenkins-Administration mit KI

Jenkins-Pipeline mit KI

Über Siemens hinaus.CODESYS, Beckhoff, Rockwell.

CODESYS

Beckhoff TwinCAT

Rockwell Studio 5000

Was Kundenwirklich fragen.

2 Wochen.4.900 EUR.SPS-Pipeline.

Verwandte Artikel

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

Industrial DevOps: Der komplette Leitfaden

Jenkins vs. GitLab CI vs. Azure DevOps

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

Erstgespräch.Kostenlos.90 Tage zum Ergebnis.