CI/CD für SPS-Entwicklung: TIA-Portal mit Jenkins automatisieren
Schritt-für-Schritt-Anleitung: So automatisieren Sie Build, Test und Deployment von TIA-Portal-Projekten mit Jenkins. Inklusive Jenkinsfile-Beispiel und PLCSim-Integration.

Warum CI/CD für SPS-Entwicklung?
In der klassischen Software-Entwicklung ist Continuous Integration und Continuous Delivery (CI/CD) seit Jahren Standard. Jede Code-Änderung wird automatisch gebaut, getestet und — bei Erfolg — deployt. Das Ergebnis: weniger Fehler, schnellere Releases, zufriedenere Teams.
In der SPS-Entwicklung sieht die Realität anders aus. TIA-Portal-Projekte werden manuell kompiliert, per USB-Stick oder Netzlaufwerk verteilt und ohne systematische Tests auf die Anlage übertragen. Versionierung? Oft eine Kopie des Projektordners mit Datum im Namen.
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 — von der Versionskontrolle bis zum automatisierten Deployment.
Was Sie nach diesem Artikel können
- TIA-Portal-Projekte in Git versionieren (diff-fähig)
- Eine Jenkins-Pipeline für automatisierten Build konfigurieren
- PLCSim Advanced für automatisierte Tests einbinden
- Quality Gates mit Code-Analyse und Compliance-Checks definieren
- Ein kontrolliertes Deployment-Konzept für SPS-Code entwickeln
Architektur-Überblick
Die CI/CD-Pipeline für SPS-Entwicklung unterscheidet sich in einigen Punkten grundlegend von klassischen Software-Pipelines. Die wichtigsten Unterschiede:
| 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) |
Diese Unterschiede machen deutlich: Man kann nicht einfach eine IT-Pipeline 1:1 auf die OT-Welt übertragen. Es braucht einen angepassten Ansatz, der die Besonderheiten von SPS-Entwicklung respektiert.
Die 6 Stages der SPS-CI/CD-Pipeline
Vom Git-Commit bis zum kontrollierten Deployment — jede Stage im Detail.
Checkout
SPS-Quellcode aus Git-Repository auschecken. TIA-Portal-Projekte werden als Verzeichnisstruktur oder als exportierte XML-Dateien versioniert.
Build
TIA-Portal-Projekt im Headless-Modus kompilieren. Die TIA Openness API ermöglicht automatisierte Builds ohne GUI-Interaktion.
Simulate
Kompilierten Code auf PLCSim Advanced laden und gegen virtuelle Anlagenmodelle testen. Hardware-in-the-Loop ohne physische Hardware.
Test
Automatisierte Funktionstests, Regressionstests und Grenzwerttests ausführen. Testergebnisse werden als JUnit-XML exportiert.
Quality Gate
Code-Analyse, Namenskonventionen, Sicherheitsregeln und Compliance-Checks prüfen. Bei Verstoß wird die Pipeline gestoppt.
Deploy
Artefakte in ein Release-Repository überführen. Deployment auf die Ziel-SPS erfolgt kontrolliert im geplanten Wartungsfenster.
Jenkinsfile: Das komplette Beispiel
Das folgende Jenkinsfile zeigt eine vollständige Pipeline für ein TIA-Portal-Projekt. Es dient als Startpunkt — passen Sie Pfade, Projektnamen und Qualitätskriterien an Ihre Umgebung an.
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 '''
# TIA Openness Headless Build
$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"
}
echo "Build erfolgreich -
keine Kompilierfehler"
'''
}
}
stage('Simulate & Test') {
steps {
powershell '''
# PLCSim Advanced starten
Start-PLCSimInstance -Name "TestPLC"
# Programm auf Simulations-SPS laden
Download-ToPlcSim -Project ${env:PROJECT_PATH}
# Automatisierte Tests ausführen
Invoke-PlcTests -TestSuite "tests/"
-OutputFormat "junit"
-OutputPath "test-results/"
# Simulation beenden
Stop-PLCSimInstance -Name "TestPLC"
'''
}
post {
always {
junit 'test-results/*.xml'
}
}
}
stage('Quality Gate') {
steps {
powershell '''
# Namenskonventionen prüfen
Test-NamingConventions -Path ${env:PROJECT_PATH}
# Sicherheitsregeln nach IEC 62443
Test-SecurityCompliance -Standard "IEC62443"
# Ungenutzte Variablen finden
Test-UnusedVariables -Path ${env:PROJECT_PATH}
'''
}
}
stage('Package') {
steps {
powershell '''
# Release-Artefakt erstellen
$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 '''
# Kontrolliertes Deployment
Deploy-ToStagingPlc
-Package "release/MyPlcProject-*.zip"
-Target "192.168.1.100"
'''
}
}
}
post {
success {
echo "Pipeline erfolgreich abgeschlossen"
}
failure {
echo "Pipeline fehlgeschlagen"
// E-Mail-Benachrichtigung an Team
}
}
}Wichtiger Hinweis
Die PowerShell-Cmdlets in diesem Beispiel sind vereinfacht dargestellt. In der Praxis benötigen Sie Wrapper-Scripts, die die TIA Openness API korrekt ansprechen und Fehlerbehandlung implementieren. Wir stellen unseren Kunden erprobte Script-Bibliotheken zur Verfügung.
Voraussetzungen: Was Sie brauchen
TIA Portal V18 oder höher
Ältere Versionen unterstützen TIA Openness nur eingeschränkt. Ab V18 ist Headless-Build zuverlässig möglich.
Jenkins-Server mit Windows-Agent
TIA Portal läuft nur unter Windows. Der Jenkins-Agent benötigt eine lizenzierte TIA-Portal-Installation.
PLCSim Advanced V5+
Für automatisierte Simulation und Tests. Die Advanced-Variante unterstützt API-Zugriff und mehrere Instanzen.
Git-Repository
TIA-Portal-Projekte müssen als Verzeichnisstruktur (nicht als einzelne .zap-Datei) gespeichert werden, um diff-fähig zu sein.
Netzwerkzugang
Der Jenkins-Agent muss Zugriff auf das Git-Repository und optional auf die Ziel-SPS oder ein Staging-System haben.
Git-Strategie für TIA-Portal-Projekte
Die Versionierung von SPS-Projekten in Git ist der erste und wichtigste Schritt. Ohne saubere Versionskontrolle ist CI/CD nicht möglich. Hier die empfohlene Strategie:
Projektstruktur im Repository
Branching-Modell
Für SPS-Projekte empfehlen wir ein vereinfachtes Git-Flow-Modell:
5 typische Fallstricke — und wie Sie sie vermeiden
Aus über 500 Projekten kennen wir die häufigsten Stolperstellen bei der CI/CD-Einführung für SPS-Entwicklung.
Binäre Projektdateien
TIA-Portal speichert standardmäßig binäre .zap-Dateien, die nicht diff-fähig sind.
Projekte als Verzeichnisstruktur speichern und die TIA Openness API für XML-Export nutzen. So werden Änderungen in Git nachvollziehbar.
Lizenzverwaltung
Jeder Jenkins-Agent benötigt eine eigene TIA-Portal-Lizenz. Bei mehreren parallelen Builds steigen die Kosten.
Floating Licenses nutzen und die Anzahl paralleler Builds begrenzen. Alternativ: einen dedizierten Build-Agent mit Exklusiv-Lizenz einsetzen.
Lange Build-Zeiten
TIA-Portal-Kompilierung kann bei großen Projekten 10–30 Minuten dauern.
Inkrementelle Builds nutzen, nur geänderte Bausteine kompilieren und Build-Caching implementieren. Nightly Full-Builds für Sicherheit.
Testabdeckung
Automatisierte Tests für SPS-Code sind deutlich schwieriger als für klassische Software.
Mit Unit-Tests für Funktionsbausteine (FBs) starten, dann schrittweise Integrationstests mit PLCSim Advanced aufbauen. 100 % Abdeckung ist nicht das Ziel — 60–70 % der kritischen Pfade reichen für den Anfang.
Team-Akzeptanz
SPS-Programmierer sind oft nicht mit Git und CI/CD vertraut. Widerstand gegen neue Workflows.
Früh einbinden, Vorteile demonstrieren (z.B. "nie wieder verlorene Änderungen"), Schulungen anbieten und mit einem Pilot-Projekt starten.
Typische Ergebnisse nach der Einführung
Was unsere Kunden nach der Einführung von CI/CD für SPS-Entwicklung berichten:
weniger manuelle Deployment-Schritte
schnellere Fehleridentifikation
Nachvollziehbarkeit aller Änderungen
häufigere Releases bei weniger Fehlern
Fazit: Starten Sie mit einem Pilot-Projekt
CI/CD für SPS-Entwicklung ist kein Alles-oder-Nichts-Projekt. Beginnen Sie mit einem überschaubaren Pilot: ein einzelnes TIA-Portal-Projekt, ein Jenkins-Agent, eine einfache Pipeline mit Build und Basis-Tests. Sammeln Sie Erfahrungen, gewinnen Sie das Team und skalieren Sie schrittweise.
Die Technologie ist reif, die Tools sind verfügbar und die Vorteile sind messbar. Was es braucht, ist der Mut zum ersten Schritt — und idealerweise einen erfahrenen Partner, der die Fallstricke kennt.
Proof of Concept in 2 Wochen
Wir setzen in 2 Wochen eine funktionierende CI/CD-Pipeline für Ihr TIA-Portal-Projekt auf — zum Festpreis. Build, Test und Quality Gates inklusive. Kein Risiko, sofort nutzbar.
Bereit für den nächsten Schritt?
Vereinbaren Sie ein kostenloses Erstgespräch — wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Erstgespräch buchen