Software Defined
Automation
im Praxistest.
Software Defined Automation (SDA) überträgt DevOps-Praktiken auf die SPS-Programmierung: Git-Versionierung, CI/CD-Pipelines, automatisierte Tests, Code Reviews. Ein Erfahrungsbericht aus einem achtwöchigen Pilot bei einem Maschinenbauer — und was dabei gewirkt hat.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
Fünf Sätze,
die reichen
wenn die Zeit knapp ist.
- /01SDA = CI/CD für SPSGit-Versionierung, Pull Requests und CI-Pipelines für TIA Portal, Studio 5000, TwinCAT, B&R und CODESYS.
- /02Pilot-Ergebnis40 % kürzere Lead Time für SPS-Änderungen, spürbar weniger Inbetriebnahme-Iterationen, lückenloser Audit-Trail.
- /03ZeitrahmenErster funktionierender Workflow in 6–10 Wochen, vier klar strukturierte Phasen.
- /04Größter Hebelnicht das Tool, sondern Branching-Strategie, Review-Kultur und IT/OT-Brückenbau.
- /05ZielgruppeMaschinen- und Anlagenbauer mit 5+ SPS-Entwicklern, Compliance-Anforderungen (IEC 62443, NIS2, CRA).
DevOps-Praktiken
für die
SPS-Programmierung.
Software Defined Automation (SDA) ist ein Ansatz, bei dem DevOps-Praktiken aus der Software-Entwicklung auf die SPS-Programmierung übertragen werden: Git-basierte Versionierung, automatisierte Builds, Tests gegen virtuelle SPS, Pull-Request-Workflows 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.
Vom Nice-to-have
zum Must-have.
Wer schon einmal versucht hat, ein TIA-Portal-Projekt parallel mit fünf Leuten zu bearbeiten, kennt das Gefühl: ZIP-Dateien durchs Mailpostfach, Versionen heißen final_v2_neu_jetzt_wirklich.zap17, wer zuletzt gespeichert hat, gewinnt.
Gleichzeitig steigt der Druck: Cyber Resilience Act, NIS2 und IEC 62443 verlangen einen lückenlosen Nachweis darüber, wer wann welche Änderung an einer Steuerung vorgenommen hat. SDA ist damit nicht nur ein Produktivitäts-Thema, sondern ein Compliance-Thema.
Sechs Bausteine,
nicht sechs Versprechen.
- /01
Cloud Engineering Workspaces
Browserbasierte Engineering-Umgebung. Setup in Stunden, nicht Tagen.
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.
- /02
Git-basierte Versionierung für SPS-Code
Echte Branches, Pull Requests, Code Reviews.
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.
- /03
Virtuelle SPS für Tests und Simulation
CI/CD ohne reale Hardware. Regressionstests bei jedem Commit.
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.
- /04
CI/CD für Automatisierungsprojekte
Build, Test, Deployment und Rollback als deklarative Pipeline.
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.
- /05
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.
- /06
Vendor-Agnostischer Ansatz
Ein Workflow für gemischte Steuerungslandschaften.
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.
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. Überwiegend Siemens TIA Portal (S7-1500), ergänzt um Beckhoff TwinCAT.
Vor SDA: TIA Portal lokal auf den Notebooks, Backups per Netzlaufwerk, Inbetriebnahmen direkt an der Anlage, jede Änderung manuell. Versionsstände vorhanden — irgendwo. Tests manuell. Reviews mündlich am Schaltschrank.
- 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: Lead Time von rund fünf auf drei Arbeitstage (ca. 40 %), Inbetriebnahme-Iterationen von durchschnittlich sieben auf vier, 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.
Vier Phasen,
ein klarer Weg.
Discovery & Reifegrad
Aufnahme der bestehenden Engineering-Landschaft, Tool-Inventur, Stakeholder-Interviews mit Automatisierung, IT und Instandhaltung. Klärung der Sicherheits- und Netzwerkanforderungen.
Pilot-Setup
Anbindung 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
Aufbau 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
Schulungen, Übergabe an die internen Teams, Dokumentation, schrittweise Migration weiterer Anlagen und Aufbau eines internen „Center of Excellence" für SPS-DevOps.
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 anfordernWas wirklich
gewirkt hat.
- /01Der 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.
- /02Virtuelle SPS sind ein Gamechanger für Regressionstests, ersetzen aber keine Inbetriebnahme an realer Hardware — der Mix macht es.
- /03Automatisierungstechniker brauchen begleitende Schulung. Pull Requests, Merge-Konflikte und CI/CD-Logs sind für viele Neuland.
- /04Frühzeitig IT-Security und Netzwerkverantwortliche einbinden — gerade wenn Cloud-Workspaces auf bestehende OT-Netze zugreifen sollen.
- /05Beginnen Sie klein: eine Linie, ein Team, ein klar messbares Ziel. Erst wenn die Schleife rund läuft, weitere Anlagen anschließen.
- /06Messen 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 schnell rechnet, und solchen, in denen der Aufwand den Nutzen übersteigt.
- /01Maschinen- und Anlagenbauer mit 5+ SPS-Entwicklern
- /02Serienmaschinenbau mit häufigen Varianten und Kundenanpassungen
- /03Gemischte Steuerungslandschaften (Siemens + Rockwell + Beckhoff)
- /04Compliance-getriebene Branchen: ISO 26262, IEC 62443, TISAX, NIS2, CRA
- /05Unternehmen mit international verteilten Inbetriebnahme-Teams
- /01Einzelanlagenbau mit < 3 Entwicklern und wenig Varianz
- /02Reine Legacy-Umgebungen ohne Modernisierungsbudget
- /03Teams ohne grundlegendes Git-Verständnis und ohne Schulungsbereitschaft
- /04Umgebungen, in denen IT und OT strikt voneinander abgeschottet bleiben sollen
Was Kunden
wirklich fragen.
- Q.01
- 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.
- Q.02
- 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.
- Q.03
- 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.
- Q.04
- 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.
- Q.05
- 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.
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.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance