Wie funktioniert CI/CD für SPS-Entwicklung?

CI/CD für SPS-Entwicklung automatisiert den gesamten Prozess von der Code-Änderung bis zum Deployment auf der Steuerung. Über die Siemens Openness-API lassen sich TIA-Portal-Projekte exportieren, kompilieren und mit PLCSim automatisiert testen. Jenkins, GitLab CI oder Azure DevOps orchestrieren den Workflow. Analog funktioniert der Ansatz mit Beckhoff TwinCAT 3 Source Control und CODESYS.

Kann man TIA Portal mit Jenkins automatisieren?

Ja. Die Siemens TIA Portal Openness-API ermöglicht die Steuerung von TIA Portal über externe Skripte. Jenkins kann Projekte öffnen, kompilieren, exportieren und mit PLCSim Advanced automatisierte Tests ausführen. Quality Gates prüfen Code-Qualität und Testabdeckung. Das Version Control Interface (VCI), seit TIA Portal V18 Teil der Installation, legt die Bausteine als Dateien ab, die Git versioniert und die ein Reviewer im Pull Request liest.

Wie versioniert man Steuerungscode mit Git?

Steuerungscode kann nach dem Export aus TIA Portal, CODESYS oder TwinCAT als textbasierte Dateien (XML, L5X, ST) in Git versioniert werden. Mit Branches arbeiten mehrere Programmierer parallel an einem Projekt, Pull Requests sorgen dafür, dass jede Änderung ein zweites Paar Augen sieht. Seit TIA Portal V21 schreibt das VCI auch KOP, FUP und SCL im Textformat SIMATIC SD, sodass Git die Änderung Zeile für Zeile anzeigt statt als unlesbaren XML-Block.

Was ist Release-Management für die Produktion?

Release-Management für OT-Umgebungen berücksichtigt geplante Wartungsfenster, Safety-Anforderungen und Rollback-Strategien. Releases werden in Staging-Umgebungen validiert, bevor sie kontrolliert auf Produktionsanlagen ausgerollt werden. Automatisierte Smoke-Tests verifizieren die Funktionsfähigkeit nach dem Deployment.

Was ist SPS-Testautomatisierung?

SPS-Testautomatisierung nutzt PLCSim oder PLCSim Advanced, um Steuerungsprogramme ohne physische Hardware zu testen. Unit-Tests prüfen einzelne Funktionsbausteine, Integrationstests simulieren komplette Anlagenszenarien. Die Tests laufen automatisch in der CI/CD-Pipeline bei jeder Code-Änderung.

Was ist der Unterschied zwischen PLCSIM und PLCSIM Advanced?

PLCSIM ist der Simulator für das interaktive Testen am Engineering-Rechner, PLCSIM Advanced erzeugt virtuelle Steuerungen, die sich über eine Programmierschnittstelle (Runtime-API) fernsteuern lassen. Für eine Pipeline ist genau diese API der Unterschied: Ein Skript startet die Instanz, lädt das Programm, setzt Eingänge und liest Ausgänge, ohne dass jemand klickt. Seit Version 8.0 simuliert PLCSIM Advanced neben S7-1500 und ET 200SP auch die S7-1200 G2.

Was hat virtuelle Inbetriebnahme mit CI/CD zu tun?

Virtuelle Inbetriebnahme testet den Steuerungscode gegen ein Simulationsmodell der Anlage, bevor die echte Maschine steht. Meist geschieht das einmal, kurz vor der Abnahme, mit viel Handarbeit. Eine CI/CD-Pipeline macht den wiederholbaren Teil daraus zur Routine: Dieselben Testfälle gegen PLCSim Advanced laufen bei jeder Änderung, auch Monate nach der Auslieferung, wenn ein Kunde ein Update braucht.

Wie erfüllt eine CI/CD-Pipeline IEC 62443 im Maschinenbau?

Eine IEC-62443-konforme Pipeline integriert Secret-Scanning, Software Bill of Materials (SBOM), signierte Artefakte und dokumentierte Security-Freigaben als verpflichtende Stages. Die Pipeline erzeugt automatisch die Nachweise, die für eine Zertifizierung nach IEC 62443-4-1 (Secure Development Lifecycle) und -4-2 (Komponenten) erforderlich sind, von der CVE-Überwachung bis zum Audit-Log.

Was ändert sich durch den Cyber Resilience Act für Maschinenbauer?

Der EU Cyber Resilience Act (CRA) gilt für Produkte mit digitalen Elementen, und das schließt Maschinen und Anlagen explizit ein. Seit dem 11.09.2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden per Frühwarnung melden, auch für bereits ausgelieferte Maschinen. Ab dem 11.12.2027 gelten alle Pflichten, darunter SBOM und fünf Jahre Sicherheitsupdates. Moderne CI/CD-Pipelines generieren diese Artefakte automatisiert; manuelle Prozesse werden in der Breite nicht skalieren.

Welche Pipeline-Nachweise brauche ich für IEC 61508 Safety?

Für den Nachweis nach IEC 61508 (SIL 1–4) müssen Pipelines die lückenlose Traceability von Anforderung → Design → Code → Test bereitstellen. Konkret: versionierte Lastenhefte, Code-Coverage-Reports, Review-Protokolle, Testergebnisse aus Unit-, Integrations- und HiL-Tests sowie ein unveränderliches Audit-Log. Jenkins-Pipelines archivieren diese Artefakte automatisch pro Release.

Was ändert TIA Portal V21 an der Git-Versionierung?

TIA Portal V21 erweitert das Textformat SIMATIC Source Documents (SIMATIC SD) auf KOP, FUP, SCL und Bausteine mit gemischten Sprachen, sodass das Version Control Interface diese Bausteine als lesbaren, diff-fähigen Text ablegt. Git selbst ist nicht in die Oberfläche eingebaut: Das VCI synchronisiert das Projekt mit einem Arbeitsordner, Commit, Branch und Pull Request laufen weiter über einen normalen Git-Client. Für die Pipeline heißt das weniger PowerShell-Code, weil der Export über Openness als SIMATIC SD statt als XML kommt und Reviews ohne Umwege lesbar sind. Bestehende VCI- oder Openness-Projekte stellen wir auf das neue Format um.

Wie funktioniert GitOps für SPS-Steuerungen?

GitOps für SPS funktioniert hybrid: Edge-Workloads (OPC UA Gateways, Datenpumpen, Container auf Industrie-PCs) werden vollständig per Argo CD oder Flux aus Git ausgerollt. Der eigentliche SPS-Programmstand wird per Pipeline gebaut und versioniert, das Aufspielen erfolgt aber in geplanten Wartungsfenstern mit Approval-Gate, PLCSim-Smoke-Test und Rollback-Brücke. So bleibt die Anlagenverfügbarkeit gesichert und der Audit-Trail nach IEC 62443-4-1 vollständig.

Welche Programmiersprache nutzt man für SPS?

SPS-Programme werden in den fünf Sprachen der Norm IEC 61131-3 geschrieben: Kontaktplan (KOP), Funktionsplan (FUP), Anweisungsliste (AWL), Strukturierter Text (SCL/ST) und Ablaufsprache (AS). Für die Brücke in die IT-Welt kommt zunehmend C# hinzu, etwa über die Open-Source-Bibliothek S7.NetPlus oder Beckhoff TwinCAT.NET. Echtzeit-Logik bleibt jedoch bei IEC 61131-3.

Was gehört alles zu CI/CD?

Zu CI/CD gehören fünf Bausteine: Commit und Versionierung im Git-Repository, ein automatischer Build beziehungsweise Compile, automatisierte Tests, Quality- und Security-Gates sowie Deployment und Release. Auf SPS-Code übertragen heißt das: Export per Openness-API, Kompilieren, PLCSim-Tests, IEC-62443-Gates und kontrolliertes Aufspielen im Wartungsfenster, jeder Schritt nachvollziehbar protokolliert.

Wie lange dauert die Einführung von CI/CD für SPS?

Die Einführung dauert typischerweise rund 90 Tage und läuft in vier Schritten ab: Git für TIA Portal etablieren, Jenkins-Pipelines aufbauen, Simulation und Testautomatisierung mit PLCSim integrieren und den IT/OT-Kulturwandel begleiten. Den Start machen Sie risikoarm mit einem Proof of Concept zum Festpreis, der eine erste Pipeline produktiv übergibt.

CI/CD für SPS-Steuerungen im Maschinenbau

CI/CD für TIA Portal, CODESYS und TwinCAT: Git-Versionierung, automatisierte PLCSim-Tests, Jenkins-Pipelines und IT/OT-Kulturwandel, für den Maschinenbau im deutschsprachigen Raum.

Erstgespräch buchen Whitepaper herunterladen

SEIT 2006 · 47+ PROJEKTE · MASCHINENBAU · AUTOMOTIVE · INDUSTRIE

Aktualisiert · 2026-10-03//Autor · Andreas Schönfeld, Comquent GmbH//Lesezeit · 12 min//TIA Portal V21 · PLCSIM Advanced V8.0 · Jenkins LTS 2.568 · TwinCAT 3.1 Build 4026//Standort · Puchheim bei München

// TIA Portal V21

Seit V21 sind Git-Diffs für KOP, FUP und SCL lesbar.

Das Version Control Interface schreibt diese Bausteine jetzt im Textformat SIMATIC SD statt als XML. Git bleibt ein eigenes Werkzeug neben TIA Portal, aber ein Reviewer sieht im Pull Request endlich, welche Zeile sich geändert hat.

Umstieg besprechen Versionsmatrix V16 bis V21 →

// 01Definition

Was ist CI/CD für
SPS und Maschinenbau?

CI/CD für SPS ist die automatisierte Strecke aus Build, Test und Deployment von Steuerungscode: Eine Pipeline kompiliert, prüft und versioniert SPS-Programme aus TIA Portal, CODESYS oder TwinCAT über Git und Jenkins statt manueller Übertragung per USB-Stick. Kernbausteine sind das Version Control Interface (VCI), die Siemens Openness-API und PLCSim Advanced für Hardware-freie Tests.

Wir bauen diese Strecke herstellerübergreifend und ergänzen sie um IEC-62443-Gates. Am längsten dauert danach etwas, das kein Werkzeug übernimmt. Steuerungstechnik und IT müssen sich auf einen gemeinsamen Freigabeweg einigen. Sitz ist Puchheim bei München, gearbeitet wird in ganz DACH.

Wie testet man SPS-Code, ohne eine Anlage zu blockieren?

Mit einer virtuellen Steuerung. PLCSim Advanced bildet eine S7-1500 und seit Version 8.0 auch eine S7-1200 G2 so weit nach, dass Bausteine, Schrittketten und Verriegelungen ohne reale Hardware durchlaufen. Bei CODESYS übernimmt das der Test Manager, bei Beckhoff TcUnit, bei Rockwell FactoryTalk Logix Echo. In der Pipeline startet ein Skript den Simulator über dessen API nach dem Compile, spielt eine Testsuite ab und hängt das Protokoll an das Artefakt. Die Maschine selbst brauchen Sie erst wieder, wenn die Logik einmal grün war.

Wer unterstützt Maschinenbauer bei CI/CD für Steuerungssoftware?

Drei Gruppen kommen infrage: die Steuerungshersteller mit ihren Engineering-Diensten, klassische Automatisierungs-Systemhäuser und DevOps-Beratungen mit OT-Erfahrung. Der Unterschied liegt selten im Leistungsumfang, sondern in der Frage, wer die Pipeline nach der Übergabe betreibt. Wir übergeben sie an Ihr Team und können den laufenden Betrieb als Automation as a Service mitnehmen.

Virtuelle Inbetriebnahme: Ein Steuerungstechniker sitzt vor zwei Monitoren mit dem Drahtgittermodell einer Förderanlage mit Robotern und grünen und orangefarbenen Pipeline-Statusbalken, hinter einer Glaswand die Maschinenhalle mit halb verdrahteter Anlage und offenem Schaltschrank — Am Schreibtisch läuft die Anlage schon als Modell, in der Halle dahinter ist sie noch nicht fertig verdrahtet. Wer die Logik in dieser Phase gegen PLCSim Advanced prüft, bringt einen getesteten Stand an die Maschine. Das ist virtuelle Inbetriebnahme, und die Pipeline wiederholt sie bei jeder Änderung.

// Pipeline — vom Commit zum signierten Artefakt

178 Tsd.

Arbeitskräfte fehlen dem deutschen Maschinenbau bis 2034.

Quelle · IW-Studie für den VDMA

133 Tsd.

Fachkräfte fehlen 2028 in Digitalisierungsberufen.

Quelle · IW Köln 2025

−80 %

Deployment-Zeit in Comquent-Referenzprojekten (Median).

Basis · 6 Projekte 2022–2025

2027

Cyber Resilience Act wird für Maschinen verbindlich.

Bußgeld bis 15 Mio. € / 2,5 % Weltumsatz

Quelle · EU 2024/2847, Art. 64

// Das Spannungsfeld

Wo treffen sich
IT und OT?

In der Pipeline. Die Steuerungstechnik arbeitet mit TIA Portal und Projektordnern, die IT mit Git, Tickets und Build-Servern. Erst eine gemeinsame CI/CD-Strecke sorgt dafür, dass beide denselben Stand sehen, statt ihn per USB-Stick oder Netzlaufwerk weiterzureichen.

Werkbank vor einem offenen Schaltschrank: ein abgegriffener USB-Stick, ein Laptop voller Aufkleber, ein ausgedruckter Kontaktplan mit Bleistiftnotizen und ein Beschriftungsgerät, im Schrank leuchtet eine orangefarbene Meldeleuchte — // AusgangslageEin USB-Stick, ein Laptop mit Aufklebern aus drei Projekten, ein ausgedruckter Kontaktplan mit Bleistiftnotizen. Welcher dieser Stände gerade in der Steuerung läuft, steht nirgends.

// 02Herausforderungen

Wo stocken
SPS-Projekte heute?

An diesen Stellen bleiben Projekte in dieser Branche am häufigsten hängen. Wie wir sie angehen, steht im nächsten Abschnitt.

/01
Keine Versionskontrolle für SPS-Code
SPS-Programme liegen auf USB-Sticks oder Netzlaufwerken. Es gibt keine Nachvollziehbarkeit, wer wann was geändert hat, und verschiedene Stände auf verschiedenen Maschinen machen jede Ferndiagnose zum Ratespiel. Falls Ihnen dieser Ordner bekannt vorkommt: In der Steuerungstechnik ist er der Regelfall, denn die Toolchain gab es jahrelang schlicht nicht her.
/02
Manuelle Deployments auf Maschinen
Ein Inbetriebnehmer spielt jedes Update vor Ort per Laptop ein, ohne festen Ablauf. Welcher Stand danach auf der Maschine läuft, weiß oft nur er. Bei zehn Anlagen ist das mühsam, bei hundert nicht mehr zu leisten.
/03
Keine automatisierten Tests
Getestet wird der SPS-Code erst an der realen Anlage, oft unter Zeitdruck bei der Inbetriebnahme. PLCSim ist auf vielen Engineering-Rechnern installiert, aber es startet ihn jemand von Hand. Einen Testlauf, der bei jeder Änderung von selbst anläuft, gibt es selten.
/04
IT/OT-Kluft
IT und SPS-Programmierung arbeiten mit getrennten Werkzeugen und getrennten Freigabewegen. Die IT denkt in Tickets und Merge Requests, die Steuerungstechnik in Wartungsfenstern und Abnahmen. Solange niemand die beiden Abläufe verbindet, wartet jedes Projekt an der Übergabe.

// 03Unser Ansatz

Wie gelingt der Einstieg in
SPS-CI/CD?

Vier Schritte, die wir in dieser Reihenfolge gehen. Der erste bringt noch keine Pipeline, sondern Klarheit darüber, welcher Softwarestand heute wo läuft.

Schritt / 01

Git für TIA Portal einführen

Strukturierte Einführung von Git als Versionskontrollsystem für TIA-Portal-Projekte. Branch-Strategien, Merge-Workflows und Code-Reviews, angepasst an die Arbeitsweise von SPS-Programmierern.

Schritt / 02

Jenkins-Pipelines für SPS

Aufbau automatisierter Build- und Deployment-Pipelines mit Jenkins. Vom Commit bis zum fertigen SPS-Programm: kompilieren, Syntax-Check, Quality Gates und automatisierte Dokumentation.

Schritt / 03

Simulation und Test-Automatisierung

PLCSim Advanced läuft als Stage in der CI-Pipeline. Ein Skript startet über die Runtime-API eine virtuelle Steuerung, lädt das Programm und spielt Funktions- und Regressionstests ab, bevor der Code auf die reale Anlage kommt. Fehler zeigen sich damit am Schreibtisch statt bei der Inbetriebnahme.

Schritt / 04

Kulturelles Coaching IT/OT

Workshops, in denen SPS-Ingenieure und IT an derselben Pipeline arbeiten statt übereinander zu reden. Mit beiden Teams legen wir fest, wer welche Freigabe erteilt, und messen, ob sich Durchlaufzeit und Fehlerquote bewegen.

// 04Ergebnisse

Was liefern
SPS-Pipelines?

Eine SPS-Pipeline liefert zu jeder Änderung einen kompilierten Programmstand, der gegen eine virtuelle Steuerung getestet wurde, bei Siemens gegen PLCSim Advanced. Die exportierten Bausteine, das Testprotokoll und die SBOM archiviert sie als Artefakt dazu. Damit ist für jede Steuerung nachvollziehbar, welcher Stand aufgespielt wurde, wer ihn freigegeben hat und welche Tests er bestanden hat. Die Tabelle zeigt, was sich dadurch im Alltag verschiebt.

Messgröße

Vorher

Nachher

Ergebnis

/01

Deployment-Zeit

Stunden

-80%

→

/02

Fehlerrate

Hoch

-60%

→

/03

Versionskonflikte

Im Feld entdeckt

Im Build erkannt

→

/04

Inbetriebnahme-Dauer

Tage

Stunden

→

/05

Code-Nachvollziehbarkeit

Nicht gegeben

100%

→

/06

Team-Zusammenarbeit

Isoliert

Integriert

→

// 05Technologien

Welche Werkzeuge braucht
SPS-CI/CD?

Womit wir in diesem Umfeld arbeiten. Die Auswahl richtet sich nach der Toolchain, die bei Ihnen schon läuft, nicht nach unserer Präferenz.

/01

TIA Portal

/02

Siemens Openness API

/03

TIA Portal VCI

/04

Beckhoff TwinCAT 3

/05

CODESYS

/06

Rockwell Studio 5000

/07

Jenkins

/08

GitLab CI

/09

Azure DevOps

/10

Git

/11

PLCSim Advanced

/12

TIA Test Suite

/13

SonarQube

/14

Docker

/15

Ansible

/16

OPC UA

// 06 — Nächster Schritt

DevOps für Ihre SPS-Entwicklung einführen?

Lassen Sie uns sprechen. In einem kostenlosen Erstgespräch klären wir, wie wir Ihre spezifischen Herausforderungen lösen können.

Erstgespräch buchen→→ Reifegrad-Check starten

// 07Plattform-Matrix

Welche Steuerungen
passen in die Pipeline?

Alle vier großen Plattformen: Siemens, Beckhoff, CODESYS und Rockwell. Der Unterschied liegt darin, wie der Code aus dem Engineering-Werkzeug als Text herauskommt und womit er sich ohne Hardware testen lässt. Die Tabelle zeigt beides je Hersteller.

Plattform

Versionskontrolle

CI-Integration

Test-Stack

/01

Siemens TIA Portal

VCI (ab V18) + Openness, SIMATIC SD ab V21

Jenkins / Azure DevOps

PLCSim Advanced, TIA Test Suite

/02

Beckhoff TwinCAT 3

Source Control ab Build 4026

Jenkins via MSBuild

TcUnit, Virtual Machine

/03

CODESYS

CODESYS Git (Add-on) + Textexport

Python-Scripting + Jenkins

CODESYS Test Manager

/04

Rockwell Studio 5000

L5X-Text-Export + Git

Jenkins via PowerShell

FactoryTalk Logix Echo, Emulate3D

Die .NET-Brücke: S7.NET, TwinCAT.NET und Git-Workflows

Zwischen Steuerung und IT-Anwendung sitzt oft C#-Code. Zwei Wege sind verbreitet. S7.NET ist eine Open-Source-Bibliothek, über die eine .NET-Anwendung Daten mit einer S7-Steuerung austauscht; auf der Steuerung selbst läuft dabei kein C#. Beckhoff TwinCAT.NET verbindet .NET-Anwendungen unter Visual Studio mit der TwinCAT-Runtime.

Für die Pipeline ist dieser Teil der einfachere. C#-Module laufen durch gewöhnliche Git-Workflows, MSBuild und NUnit-Tests und lassen sich in Jenkins, GitLab CI oder Azure DevOps kompilieren, testen und signieren, ohne dass auf dem Build-Agent eine TIA-Portal-Lizenz liegt. Harte Echtzeit-Logik wie Lageregler oder Motion Control bleibt bei IEC 61131-3 in TIA Portal, CODESYS oder TwinCAT.

Einsatzgrenzen, Toolchain und Praxisbeispiele behandelt unser ausführlicher Leitfaden: SPS mit C# programmieren →

// 08Pipeline in Aktion

Wie sieht ein Jenkinsfile für TIA Portal aus?

Jenkinsfile: TIA Portal CI

# TIA Portal CI via Openness-API + PLCSim Advanced
pipeline {
  agent { label 'tia-portal' }
  environment {
    TIA_PROJECT = 'Anlage01.ap21'
    PLCSIM_INST = 'PLCSIM-001'
  }
  stages {
    stage('Checkout') {
      steps { git url: 'https://git.example.com/plc.git' }
    }
    stage('Open & Compile') {
      steps { powershell './scripts/Compile-TiaProject.ps1 -Path $env:TIA_PROJECT' }
    }
    stage('PLCSim Smoke Tests') {
      steps { powershell './scripts/Run-PLCSim-Tests.ps1 -Suite smoke' }
    }
    stage('IEC 62443 Gates') {
      steps { powershell 'syft dir:. -o cyclonedx-json=sbom.json' }
    }
    stage('Export Artifacts') {
      steps { powershell './scripts/Export-Blocks.ps1 -Format SimaticSD -Out artifacts/' }
    }
  }
  post {
    always { archiveArtifacts 'artifacts/**, sbom.json' }
  }
}

“

Vorher haben wir Versionskonflikte im Feld entdeckt. Heute fallen sie im Jenkins durch, nicht an der Maschine.

— Leiter SPS-Entwicklung
Sondermaschinenbauer (Bayern), 2024

// 09GitOps für SPS

Wie weit trägt GitOps
bei der SPS?

Bei GitOps liegt der gewünschte Anlagenstand versioniert in Git, und ein Werkzeug gleicht den tatsächlichen Stand laufend dagegen ab. Zum Anlagenstand gehören das kompilierte Programm, die Hardware-Konfiguration, Rezepte und Parameter.

Eine Steuerung, die gerade produziert, darf dieser Abgleich aber nicht von selbst neu laden. Im Maschinenbau läuft GitOps deshalb zweigeteilt. Argo CD oder Flux halten die Edge-Schicht auf Industrie-PCs und Kubernetes am Rand der Anlage automatisch auf Soll. Die SPS bekommt ihren Programmstand über eine Pipeline, mit Freigabe und im Wartungsfenster.

// Topologie — Edge auto-reconciled, SPS gated

/01
Was funktioniert: deklarative Edge-Schicht
Konfigurationen, Container, Edge-Workloads (Node-RED, OPC UA Gateways, Datenpumpen) lassen sich vollständig per Git → Argo CD/Flux ausrollen. Drift wird automatisch erkannt und korrigiert.
/02
Was eingeschränkt geht: SPS-Programmstand
Der Programmstand (TIA, CODESYS, TwinCAT) wird per CI gebaut und in Git versioniert. Das Aufspielen erfolgt geplant in Wartungsfenstern, mit Pipeline-Trigger statt automatischem Reconcile, um Anlagenausfälle zu vermeiden.
/03
Was nicht geht: ungeprüfter Sync auf Live-Maschinen
Reines Pull-GitOps gegen Produktions-SPS ist riskant. Comquent koppelt deshalb GitOps mit einem Approval-Gate, einem PLCSim-Smoke-Test und einer Rollback-Brücke, audit-fähig nach IEC 62443-4-1.
/04
Werkzeuge in der Praxis
Git als Source of Truth, Jenkins oder GitLab CI für Build und Test, Argo CD oder Flux für die Edge-Schicht, Helm und Kustomize für Konfigurationsvarianten, signierte OCI-Artefakte für die OT-Strecke.

Workshop: ArgoCD & GitOps mit KI

// 10Normen & Compliance

Was verlangen IEC 62443
und der CRA?

Security und funktionale Sicherheit laufen als Stages in der Pipeline mit, statt kurz vor dem Audit nachgereicht zu werden. Jedes Release bringt seine Nachweise als Artefakt mit. Wer als Systemhaus Steuerungen für Stadtwerke programmiert, misst sich zusätzlich an IEC 62443-2-4, der Norm für Dienstleister an der Anlage. Wie das auf Betreiberseite aussieht, zeigt der Anwendungsfall Leit- und Fernwirktechnik bei Energie- und Wasserversorgern.

/01
IEC 61131-3
Struktur- und Syntaxprüfung
Automatisierte Prüfung des Bausteine-Exports aus TIA Portal, TwinCAT oder CODESYS auf IEC-61131-3-Konformität in der CI-Stage, vor jedem Merge.
/02
IEC 61508 / IEC 61511
Functional Safety Nachweise
Safety Lifecycle mit CI-getriggerten Testnachweisen: Code-Coverage, Review-Protokolle, Trace-Matrix Anforderung → Test, alles als Pipeline-Artefakt archiviert.
/03
IEC 62443 (ISA)
OT-Security-Gates
Secret-Scanning, SBOM-Erstellung, CVE-Monitoring und signierte Artefakte direkt in der Pipeline. Audit-ready für Zertifizierung nach IEC 62443-4-1 und -4-2.
/04
Cyber Resilience Act
EU-CRA (Meldepflicht seit 11.09.2026)
Alle Pflichten ab 11.12.2027: verpflichtende SBOM, Vulnerability-Handling und 5-Jahre-Support für Maschinen mit digitalen Komponenten. Comquent-Pipelines erzeugen die Nachweise automatisch.

DevSecOps & IEC 62443 → Blog SBOM erstellen → Anleitung Cyber Resilience Act → Maschinenbau

// 11Für wen genau?

Wer entscheidet
über die Einführung?

Meist drei Stellen zugleich: die Produktionsleitung, die SPS-Entwicklung und die Geschäftsführung. Jede stellt eine andere Frage, und jede braucht eine eigene Antwort, bevor das Projekt startet.

/01 · Stillstandszeit, Rollback, Wartungsfenster

Produktionsleitung / OT

Weniger Überraschungen in der Inbetriebnahme, reproduzierbare Anlagenstände und kontrollierte Release-Fenster statt „es hat gestern noch funktioniert".

Mehr erfahren

/02 · Git-Workflow, weniger manuelle Arbeit

SPS- / Automatisierungsingenieur

Branches statt Projekt_v7_final_final. Code-Reviews statt Copy-Paste. PLCSim-Tests statt Debug an der Maschine. Das Engineering-Werkzeug bleibt das, das Sie kennen: TIA Portal, CODESYS oder TwinCAT.

Mehr erfahren

/03 · Skalierung, Compliance, TCO

CTO / Head of Engineering

Eine Pipeline für die gesamte Anlagenflotte. Nachweisbare IEC-62443- und CRA-Konformität. Messbare DORA-Metriken statt Bauchgefühl.

Mehr erfahren

// 12KI-Unterstützung

Wie unterstützt KI die
SPS-CI/CD-Entwicklung?

KI-Werkzeuge wie Claude Code beschleunigen die SPS-CI/CD-Entwicklung, indem sie PowerShell-Skripte für die Openness-API generieren, Jenkinsfiles schreiben und PLCSim-Testfälle entwerfen. Die KI arbeitet im Terminal direkt auf der Pipeline-Konfiguration, die Steuerungslogik selbst bleibt in der Hand der SPS-Ingenieure.

Konkret nimmt KI den Automatisierern die wiederkehrende Glue-Arbeit ab: das Boilerplate der Openness-Skripte, die Verdrahtung der Jenkins-Stages, das Parsen von Compile-Logs und das Aufsetzen von Quality- und IEC-62443-Gates. Statt PowerShell-Syntax nachzuschlagen, beschreiben Ihre Teams das Ziel im Klartext und prüfen den generierten Code im Review. Den Kontext aus TIA-Portal-Eigenheiten, VCI-Workflows und PLCSim-Schnittstellen bekommt die KI als Projektwissen mit, so dass die Vorschläge zur realen Toolchain passen. Das Ergebnis ist eine schneller aufgesetzte, besser dokumentierte Pipeline, ohne dass Echtzeit-relevanter Steuerungscode jemals unkontrolliert von einer KI verändert wird.

Workshop: Jenkins Pipeline & KI Blog: KI in der SPS-Programmierung

// 13Häufige Fragen

Was Maschinenbauer
wirklich fragen.

Q.01Wie funktioniert CI/CD für SPS-Entwicklung?: CI/CD für SPS-Entwicklung automatisiert den gesamten Prozess von der Code-Änderung bis zum Deployment auf der Steuerung. Über die Siemens Openness-API lassen sich TIA-Portal-Projekte exportieren, kompilieren und mit PLCSim automatisiert testen. Jenkins, GitLab CI oder Azure DevOps orchestrieren den Workflow. Analog funktioniert der Ansatz mit Beckhoff TwinCAT 3 Source Control und CODESYS.
Q.02Kann man TIA Portal mit Jenkins automatisieren?: Ja. Die Siemens TIA Portal Openness-API ermöglicht die Steuerung von TIA Portal über externe Skripte. Jenkins kann Projekte öffnen, kompilieren, exportieren und mit PLCSim Advanced automatisierte Tests ausführen. Quality Gates prüfen Code-Qualität und Testabdeckung. Das Version Control Interface (VCI), seit TIA Portal V18 Teil der Installation, legt die Bausteine als Dateien ab, die Git versioniert und die ein Reviewer im Pull Request liest.
Q.03Wie versioniert man Steuerungscode mit Git?: Steuerungscode kann nach dem Export aus TIA Portal, CODESYS oder TwinCAT als textbasierte Dateien (XML, L5X, ST) in Git versioniert werden. Mit Branches arbeiten mehrere Programmierer parallel an einem Projekt, Pull Requests sorgen dafür, dass jede Änderung ein zweites Paar Augen sieht. Seit TIA Portal V21 schreibt das VCI auch KOP, FUP und SCL im Textformat SIMATIC SD, sodass Git die Änderung Zeile für Zeile anzeigt statt als unlesbaren XML-Block.
Q.04Was ist Release-Management für die Produktion?: Release-Management für OT-Umgebungen berücksichtigt geplante Wartungsfenster, Safety-Anforderungen und Rollback-Strategien. Releases werden in Staging-Umgebungen validiert, bevor sie kontrolliert auf Produktionsanlagen ausgerollt werden. Automatisierte Smoke-Tests verifizieren die Funktionsfähigkeit nach dem Deployment.
Q.05Was ist SPS-Testautomatisierung?: SPS-Testautomatisierung nutzt PLCSim oder PLCSim Advanced, um Steuerungsprogramme ohne physische Hardware zu testen. Unit-Tests prüfen einzelne Funktionsbausteine, Integrationstests simulieren komplette Anlagenszenarien. Die Tests laufen automatisch in der CI/CD-Pipeline bei jeder Code-Änderung.
Q.06Was ist der Unterschied zwischen PLCSIM und PLCSIM Advanced?: PLCSIM ist der Simulator für das interaktive Testen am Engineering-Rechner, PLCSIM Advanced erzeugt virtuelle Steuerungen, die sich über eine Programmierschnittstelle (Runtime-API) fernsteuern lassen. Für eine Pipeline ist genau diese API der Unterschied: Ein Skript startet die Instanz, lädt das Programm, setzt Eingänge und liest Ausgänge, ohne dass jemand klickt. Seit Version 8.0 simuliert PLCSIM Advanced neben S7-1500 und ET 200SP auch die S7-1200 G2.
Q.07Was hat virtuelle Inbetriebnahme mit CI/CD zu tun?: Virtuelle Inbetriebnahme testet den Steuerungscode gegen ein Simulationsmodell der Anlage, bevor die echte Maschine steht. Meist geschieht das einmal, kurz vor der Abnahme, mit viel Handarbeit. Eine CI/CD-Pipeline macht den wiederholbaren Teil daraus zur Routine: Dieselben Testfälle gegen PLCSim Advanced laufen bei jeder Änderung, auch Monate nach der Auslieferung, wenn ein Kunde ein Update braucht.
Q.08Wie erfüllt eine CI/CD-Pipeline IEC 62443 im Maschinenbau?: Eine IEC-62443-konforme Pipeline integriert Secret-Scanning, Software Bill of Materials (SBOM), signierte Artefakte und dokumentierte Security-Freigaben als verpflichtende Stages. Die Pipeline erzeugt automatisch die Nachweise, die für eine Zertifizierung nach IEC 62443-4-1 (Secure Development Lifecycle) und -4-2 (Komponenten) erforderlich sind, von der CVE-Überwachung bis zum Audit-Log.
Q.09Was ändert sich durch den Cyber Resilience Act für Maschinenbauer?: Der EU Cyber Resilience Act (CRA) gilt für Produkte mit digitalen Elementen, und das schließt Maschinen und Anlagen explizit ein. Seit dem 11.09.2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden per Frühwarnung melden, auch für bereits ausgelieferte Maschinen. Ab dem 11.12.2027 gelten alle Pflichten, darunter SBOM und fünf Jahre Sicherheitsupdates. Moderne CI/CD-Pipelines generieren diese Artefakte automatisiert; manuelle Prozesse werden in der Breite nicht skalieren.
Q.10Welche Pipeline-Nachweise brauche ich für IEC 61508 Safety?: Für den Nachweis nach IEC 61508 (SIL 1–4) müssen Pipelines die lückenlose Traceability von Anforderung → Design → Code → Test bereitstellen. Konkret: versionierte Lastenhefte, Code-Coverage-Reports, Review-Protokolle, Testergebnisse aus Unit-, Integrations- und HiL-Tests sowie ein unveränderliches Audit-Log. Jenkins-Pipelines archivieren diese Artefakte automatisch pro Release.
Q.11Was ändert TIA Portal V21 an der Git-Versionierung?: TIA Portal V21 erweitert das Textformat SIMATIC Source Documents (SIMATIC SD) auf KOP, FUP, SCL und Bausteine mit gemischten Sprachen, sodass das Version Control Interface diese Bausteine als lesbaren, diff-fähigen Text ablegt. Git selbst ist nicht in die Oberfläche eingebaut: Das VCI synchronisiert das Projekt mit einem Arbeitsordner, Commit, Branch und Pull Request laufen weiter über einen normalen Git-Client. Für die Pipeline heißt das weniger PowerShell-Code, weil der Export über Openness als SIMATIC SD statt als XML kommt und Reviews ohne Umwege lesbar sind. Bestehende VCI- oder Openness-Projekte stellen wir auf das neue Format um.
Q.12Wie funktioniert GitOps für SPS-Steuerungen?: GitOps für SPS funktioniert hybrid: Edge-Workloads (OPC UA Gateways, Datenpumpen, Container auf Industrie-PCs) werden vollständig per Argo CD oder Flux aus Git ausgerollt. Der eigentliche SPS-Programmstand wird per Pipeline gebaut und versioniert, das Aufspielen erfolgt aber in geplanten Wartungsfenstern mit Approval-Gate, PLCSim-Smoke-Test und Rollback-Brücke. So bleibt die Anlagenverfügbarkeit gesichert und der Audit-Trail nach IEC 62443-4-1 vollständig.
Q.13Welche Programmiersprache nutzt man für SPS?: SPS-Programme werden in den fünf Sprachen der Norm IEC 61131-3 geschrieben: Kontaktplan (KOP), Funktionsplan (FUP), Anweisungsliste (AWL), Strukturierter Text (SCL/ST) und Ablaufsprache (AS). Für die Brücke in die IT-Welt kommt zunehmend C# hinzu, etwa über die Open-Source-Bibliothek S7.NetPlus oder Beckhoff TwinCAT.NET. Echtzeit-Logik bleibt jedoch bei IEC 61131-3.
Q.14Was gehört alles zu CI/CD?: Zu CI/CD gehören fünf Bausteine: Commit und Versionierung im Git-Repository, ein automatischer Build beziehungsweise Compile, automatisierte Tests, Quality- und Security-Gates sowie Deployment und Release. Auf SPS-Code übertragen heißt das: Export per Openness-API, Kompilieren, PLCSim-Tests, IEC-62443-Gates und kontrolliertes Aufspielen im Wartungsfenster, jeder Schritt nachvollziehbar protokolliert.
Q.15Wie lange dauert die Einführung von CI/CD für SPS?: Die Einführung dauert typischerweise rund 90 Tage und läuft in vier Schritten ab: Git für TIA Portal etablieren, Jenkins-Pipelines aufbauen, Simulation und Testautomatisierung mit PLCSim integrieren und den IT/OT-Kulturwandel begleiten. Den Start machen Sie risikoarm mit einem Proof of Concept zum Festpreis, der eine erste Pipeline produktiv übergibt.

Wenn Sie beim Lesen an Ihren eigenen Projektordner gedacht haben: Schicken Sie uns eine kurze Beschreibung Ihrer Toolchain. Im Erstgespräch skizzieren wir, wie die erste Pipeline für genau diese Steuerungen aussähe und was sie in den ersten vier Wochen leisten kann.

Erstgespräch buchen Reifegrad-Audit · 15 Minuten →

30 Minuten · unverbindlich · kein Vertriebsgespräch

// +Weiterlesen