Software Defined Automation einführen: CI/CD für SPS im Praxistest
Software Defined Automation (SDA) überträgt DevOps-Praktiken aus der Software-Entwicklung — Git-Versionierung, CI/CD-Pipelines, automatisierte Tests, Code Reviews — auf die SPS-Programmierung. Statt ZIP-Dateien per Mail zu verschicken, arbeiten Automatisierungsteams in versionierten Repositories mit virtuellen Steuerungen und automatisierten Deployments. In diesem Erfahrungsbericht zeigen wir, wie wir SDA in einem achtwöchigen Pilot bei einem Maschinenbauer eingeführt haben — und was dabei gewirkt hat.
- SDA = CI/CD für SPS: Git-Versionierung, Pull Requests und CI-Pipelines für TIA Portal, Studio 5000, TwinCAT, B&R und CODESYS.
- Pilot-Ergebnis: 40 % kürzere Lead Time für SPS-Änderungen, spürbar weniger Inbetriebnahme-Iterationen, lückenloser Audit-Trail.
- Zeitrahmen: Erster funktionierender Workflow in 6–10 Wochen, vier klar strukturierte Phasen.
- Größter Hebel: nicht das Tool, sondern Branching-Strategie, Review-Kultur und IT/OT-Brückenbau.
- Zielgruppe: Maschinen- und Anlagenbauer mit 5+ SPS-Entwicklern, Compliance-Anforderungen (IEC 62443, NIS2, CRA).
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
Was ist Software Defined Automation?
Software Defined Automation (SDA) ist ein Ansatz, bei dem DevOps-Praktiken aus der Software-Entwicklung auf die SPS-Programmierung übertragen werden. Dazu gehören Git-basierte Versionierung von Steuerungscode, automatisierte Builds, Tests gegen virtuelle SPS, Pull-Request-Workflows mit Code Reviews und CI/CD-Pipelines — herstellerübergreifend für Siemens TIA Portal, Rockwell Studio 5000, Beckhoff TwinCAT, B&R Automation Studio und CODESYS.
Als Plattform kombiniert Software Defined Automation Cloud-Engineering-Workspaces, ein Git-Backend, virtuelle Steuerungen und CI/CD — also genau die Werkzeuge, die wir als Industrial-DevOps-Berater bisher mit Jenkins, Git, Siemens Openness und Eigenbau-Skripten zusammensetzen mussten.
Warum CI/CD für SPS gerade jetzt relevant wird
Wer schon einmal versucht hat, ein TIA-Portal-Projekt parallel mit fünf Leuten zu bearbeiten, kennt das Gefühl: ZIP-Dateien wandern durch Mailpostfächer, Versionen heißen final_v2_neu_jetzt_wirklich.zap17, und wer zuletzt gespeichert hat, gewinnt. Gleichzeitig steigt der Druck von außen: Der Cyber Resilience Act, NIS2 und IEC 62443 verlangen einen lückenlosen Nachweis darüber, wer wann welche Änderung an einer Steuerung vorgenommen hat — eine Anforderung, die sich ohne Versionierung und automatisierte Pipelines nicht sauber erfüllen lässt.
SDA ist damit nicht nur ein Produktivitäts-Thema, sondern ein Compliance-Thema. Für Maschinen- und Anlagenbauer, die international liefern, wird CI/CD für SPS in den nächsten 24 Monaten vom Nice-to-have zum regulatorischen Must-have.
Was Software Defined Automation eigentlich macht
Cloud Engineering Workspaces
Statt lokal installierten Engineering-Tools arbeiten SPS-Programmierer in browserbasierten Workspaces. Jeder Entwickler bekommt mit wenigen Klicks eine isolierte Umgebung — inklusive der passenden Tool-Version. Lange Setup-Tage entfallen, neue Teammitglieder sind in Stunden produktiv.
Git-basierte Versionierung für SPS-Code
TIA-Portal-Projekte, Rockwell-Logix-Programme und Beckhoff-TwinCAT-Lösungen werden in Git-Repositories versioniert — mit echten Branches, Pull Requests und Code Reviews. Endlich lassen sich Änderungen nachvollziehen, vergleichen und kontrolliert zusammenführen.
Virtuelle SPS für Tests und Simulation
SDA stellt virtuelle SPS bereit, die in CI/CD-Pipelines hochgefahren werden können. Tests laufen ohne reale Hardware, Entwickler blockieren keine Produktionsanlagen mehr und Regressionstests werden bei jedem Commit automatisch ausgeführt.
CI/CD für Automatisierungsprojekte
Build, Test, Deployment und Rollback laufen über deklarative Pipelines. Quality Gates erzwingen Reviews, statische Code-Analyse und automatisierte Tests, bevor Code überhaupt in Richtung Anlage wandert.
Audit-Trail & Compliance
Wer hat wann welchen Funktionsbaustein geändert? SDA liefert lückenlose Audit-Logs und Approval-Workflows — eine harte Anforderung für regulierte Branchen, IEC 62443 und den Cyber Resilience Act.
Vendor-Agnostischer Ansatz
SDA versteht sich als Layer über den Engineering-Tools der etablierten Hersteller. Damit lassen sich gemischte Landschaften (Siemens + Rockwell + Beckhoff) mit einem konsistenten Workflow betreiben — ohne Lock-in in eine einzelne Tool-Welt.
SDA-Plattformen im Vergleich
„Software Defined Automation" ist sowohl ein Konzept als auch ein konkretes Produkt der Software Defined Automation GmbH aus Garching. Daneben gibt es weitere Plattformen, die CI/CD für SPS adressieren — mit unterschiedlichen Schwerpunkten:
| Plattform | SPS-Support | Deployment | Stärke |
|---|---|---|---|
| SDA Platform | Siemens, Rockwell, Beckhoff, B&R, CODESYS | Cloud / Hybrid | Multi-Vendor, KI-Features, Backup & Recovery |
| Copia Automation | Siemens, Rockwell, Beckhoff | Cloud | Git-native, starke Diff-Ansicht |
| tia-connect | Siemens TIA Portal | SaaS | Fokus CI/CD für TIA Portal |
| Siemens Industrial Edge | Siemens only | On-Prem / Edge | Tiefe TIA- und S7-Integration |
| Eigenbau (Jenkins + Git + Openness) | alle | On-Prem | Volle Kontrolle, hoher Betriebsaufwand |
Vergleich: Comquent Research 2026, basierend auf öffentlich verfügbaren Produktinformationen der Hersteller.
Erfahrungsbericht: SDA im Pilot bei einem Maschinenbauer
Unser Pilotkunde ist ein mittelständischer Maschinenbauer aus Süddeutschland mit rund 180 Mitarbeitern und einem zwölfköpfigen Automatisierungsteam. Das Steuerungs-Portfolio ist gemischt: überwiegend Siemens TIA Portal (S7-1500), ergänzt um Beckhoff TwinCAT für die Bewegungssteuerung. Vor SDA war die Welt klassisch: TIA Portal lokal auf den Notebooks der SPS-Techniker, Backups per Netzlaufwerk, Inbetriebnahmen direkt an der Anlage, jede Änderung manuell. Versionsstände waren vorhanden — irgendwo. Tests waren manuell. Reviews fanden mündlich am Schaltschrank statt.
Pilot-Steckbrief
- • Branche: Sondermaschinenbau (Süddeutschland, ~180 Mitarbeiter)
- • Team: 12 SPS-Entwickler, 2 IT-Ops, 1 Security-Verantwortlicher
- • Steuerungen: Siemens S7-1500 (TIA Portal v18), Beckhoff TwinCAT 3.1
- • Messzeitraum: 8 Wochen Pilot + 6 Monate Nachmessung
- • Werkzeuge: SDA-Plattform, Git, virtuelle SPS (PLCSim Advanced), statische Analyse
Wir haben in acht Wochen einen ersten Workflow aufgesetzt: Repository-Struktur in SDA, definierte Branching-Strategie, automatisierter Build, statische Analyse und ein Smoke-Test gegen eine virtuelle SPS bei jedem Pull Request. Schon im zweiten Sprint kam der erste Aha-Moment, als ein Programmierer einen Funktionsbaustein „gerade mal eben" umgebaut hat — und die Pipeline rot wurde, weil ein anderes Modul die alte Schnittstelle erwartete. Genau dieser Fehler hätte ohne SDA bei der Inbetriebnahme einen halben Tag gekostet.
Spannend war auch der kulturelle Effekt. Plötzlich gab es echte Code Reviews. Erfahrene Kollegen gaben ihr Wissen über Pull-Request-Kommentare weiter, statt es im Kopf zu behalten. Junior-Programmierer hatten zum ersten Mal eine sichere Spielwiese, in der sie experimentieren konnten, ohne eine Anlage zu blockieren.
Nach acht Wochen standen die Kennzahlen, die unseren Sponsor überzeugten: Die durchschnittliche Lead Time für eine SPS-Änderung sank von rund fünf auf drei Arbeitstage (ca. 40 %), Inbetriebnahme-Iterationen reduzierten sich von durchschnittlich sieben auf vier pro Release, und zum ersten Mal hatten Geschäftsführung und Instandhaltung einen lückenlosen Audit-Trail aller Änderungen — eine Anforderung, die im Kontext des Cyber Resilience Act ohnehin auf der Agenda stand.
Quelle: Comquent SDA-Pilot 2025/2026, Messzeitraum 6 Monate nach Go-live.
Unser Vorgehen für die SDA-Einführung
Discovery & Reifegrad
Woche 1–2Aufnahme der bestehenden Engineering-Landschaft, Tool-Inventur, Stakeholder-Interviews mit Automatisierung, IT und Instandhaltung. Klärung der Sicherheits- und Netzwerkanforderungen.
Pilot-Setup
Woche 3–5Anbindung von SDA, Aufsetzen der ersten Workspaces, Migration eines ausgewählten SPS-Projekts in ein Git-Repository, Definition der Branching-Strategie und Rollen.
CI/CD & virtuelle SPS
Woche 6–8Aufbau der Pipelines für Build, statische Analyse und automatisierte Tests gegen virtuelle SPS. Erste Quality Gates und Pull-Request-Workflows mit dem Automatisierungsteam.
Roll-out & Enablement
ab Woche 9Schulungen, Übergabe an die internen Teams, Dokumentation, schrittweise Migration weiterer Anlagen und Aufbau eines internen „Center of Excellence" für SPS-DevOps.
Kostenloser Download
SDA-Einführungs-Checkliste (PDF, 2 Seiten)
Die 18 Punkte, die wir vor jedem SDA-Pilot prüfen — Branching-Strategie, Tool-Versionen, Security-Anforderungen, Erfolgskennzahlen. Sofort einsatzbereit.
Checkliste anfordernLessons Learned aus dem Pilot
- Der größte Hebel liegt nicht im Tool, sondern in der Branching-Strategie und Code-Review-Kultur — wer Git aus der IT 1:1 in die OT überträgt, scheitert.
- Virtuelle SPS sind ein Gamechanger für Regressionstests, ersetzen aber keine Inbetriebnahme an realer Hardware — der Mix macht es.
- Automatisierungstechniker brauchen begleitende Schulung. Pull Requests, Merge-Konflikte und CI/CD-Logs sind für viele Neuland.
- Frühzeitig IT-Security und Netzwerkverantwortliche einbinden — gerade wenn Cloud-Workspaces auf bestehende OT-Netze zugreifen sollen.
- Beginnen Sie klein: eine Linie, ein Team, ein klar messbares Ziel. Erst wenn die Schleife rund läuft, weitere Anlagen anschließen.
- Messen Sie Wirkung früh: Lead Time für Änderungen, Anzahl Inbetriebnahme-Iterationen, Zeit bis zum Rollback. Diese Zahlen überzeugen Skeptiker mehr als jedes Whitepaper.
Für wen lohnt sich Software Defined Automation?
SDA ist kein Werkzeug für jedes Team. Aus unseren Projekten sehen wir eine klare Trennung zwischen Konstellationen, in denen sich die Investition in kurzer Zeit rechnet, und solchen, in denen der Aufwand den Nutzen übersteigt.
Lohnt sich
- ✅ Maschinen- und Anlagenbauer mit 5+ SPS-Entwicklern
- ✅ Serienmaschinenbau mit häufigen Varianten und Kundenanpassungen
- ✅ Gemischte Steuerungslandschaften (Siemens + Rockwell + Beckhoff)
- ✅ Compliance-getriebene Branchen: ISO 26262, IEC 62443, TISAX, NIS2, CRA
- ✅ Unternehmen mit international verteilten Inbetriebnahme-Teams
Lohnt sich (noch) nicht
- ❌ Einzelanlagenbau mit < 3 Entwicklern und wenig Varianz
- ❌ Reine Legacy-Umgebungen ohne Modernisierungsbudget
- ❌ Teams ohne grundlegendes Git-Verständnis und ohne Schulungsbereitschaft
- ❌ Umgebungen, in denen IT und OT strikt voneinander abgeschottet bleiben sollen
Fazit: Lohnt sich SDA?
Software Defined Automation ist kein Wundermittel — aber es ist die erste Plattform, die DevOps für die SPS-Welt ernst nimmt und konsequent als Produkt baut, statt sie aus IT-Bordmitteln zu basteln. Wer im Maschinen- oder Anlagenbau die Lead Time für Steuerungssoftware verkürzen, Qualität messbar machen und gleichzeitig die Compliance-Anforderungen aus NIS2, IEC 62443 und CRA erfüllen will, sollte sich SDA anschauen.
Die Einführung steht und fällt mit der Begleitung. Tools allein verändern keine Engineering-Kultur — die echte Arbeit beginnt mit Branching-Strategie, Review-Etikette, Test-Design und dem Brückenbau zwischen IT- und OT-Teams. Genau hier setzen wir an.
SDA mit Comquent einführen
Wir begleiten Maschinen- und Anlagenbauer von der ersten Reifegrad-Analyse über das SDA-Pilotprojekt bis zum produktiven Roll-out. Inklusive Git-Strategie, CI/CD-Pipelines, Test-Automatisierung gegen virtuelle SPS und Schulung Ihrer Automatisierungs- und IT-Teams. Lassen Sie uns in einem kostenlosen 30-Minuten-Erstgespräch klären, ob SDA zu Ihrer Landschaft passt — und wie ein realistischer Pilot bei Ihnen aussehen könnte.
Häufig gestellte Fragen zu Software Defined Automation
Was ist Software Defined Automation (SDA)?
SDA ist eine Plattform, die DevOps-Praktiken in die Welt der industriellen Steuerungen bringt: Git-basierte Versionierung von SPS-Code, virtuelle SPS, automatisierte Tests, CI/CD-Pipelines und Code-Review-Workflows — herstellerübergreifend für Siemens, Rockwell, Beckhoff und weitere.
Welche Probleme löst SDA in der Automatisierung?
Fehlende Versionierung, manuelle Tests an realer Hardware, langsame Release-Zyklen, fehlende Nachvollziehbarkeit und Vendor-Lock-in. Durch Cloud-Workspaces und virtuelle SPS können Teams parallel arbeiten und ihren Code automatisiert testen, ohne Anlagen zu blockieren.
Wie lange dauert die Einführung von SDA?
Ein fokussiertes Pilotprojekt mit einer Maschine oder Linie lässt sich in 6 bis 10 Wochen aufsetzen. Der Roll-out auf weitere Anlagen folgt schrittweise, begleitet durch Schulungen und definierte Branching-Strategien.
Ersetzt SDA Tools wie TIA Portal oder Studio 5000?
Nein. SDA versteht sich als Layer über den Engineering-Tools der Hersteller. Die eigentliche SPS-Programmierung erfolgt weiterhin in den bekannten Werkzeugen — SDA bringt Versionierung, Tests, Reviews und CI/CD darum herum.
Unterstützt Comquent die Einführung von SDA?
Ja. Comquent begleitet die Einführung von SDA von der Reifegrad-Analyse über das Pilotprojekt bis zum produktiven Roll-out — inklusive Git-Strategie, CI/CD-Pipelines, Test-Automatisierung und Schulung der Automatisierungs- und IT-Teams.
Verwandte Artikel
CI/CD für SPS: TIA-Portal mit Jenkins
SPS-Programmierung automatisieren mit Jenkins, Git-Versionierung und PLCSim-Tests.
SPS Versionsverwaltung mit Git
Tools, Vorgehen und Compliance-Aspekte für die Versionierung industrieller Steuerungen.
IT/OT-Kulturwandel in der Fertigung
Warum cross-funktionale Teams die größte DevOps-Herausforderung sind.
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 buchenVon Comquent-Experten beraten — seit 2006 | 47+ erfolgreiche Projekte | Industrie, Automotive, Finance