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
Software Defined Automation (SDA) ist ein Ansatz, der DevOps-Praktiken auf die SPS-Programmierung überträgt: Git-Versionierung von Steuerungscode, automatisierte Tests gegen virtuelle SPS, Code Reviews per Pull Request und CI/CD-Pipelines — herstellerübergreifend für Siemens, Rockwell, Beckhoff, B&R und CODESYS. Im Maschinenbau verkürzt das die Lead Time für Änderungen um bis zu 40 %.
Stand: Mai 2026 · SDA Platform · TIA Portal V21 · PLCSim Advanced V5+ · IEC 62443
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.
Wie unterscheidet sich SDA von
klassischer SPS-Automatisierung?
Klassisch arbeiten SPS-Programmierer lokal im Engineering-Tool, tauschen ZIP-Dateien per Mail und testen direkt an der Anlage. SDA verlagert denselben Code in Git, ersetzt mündliche Reviews durch Pull Requests und Tests an realer Hardware durch automatisierte Pipelines gegen virtuelle SPS — die fünf zentralen Unterschiede:
- /01VersionierungKlassisch
ZIP-Dateien auf Netzlaufwerken, „final_v2_neu.zap17“
Mit SDAGit-Repository mit echten Branches, Diff-Ansicht und History
- /02Code ReviewKlassisch
mündlich am Schaltschrank — oder gar nicht
Mit SDAPull Requests mit dokumentierten Review-Kommentaren
- /03TestsKlassisch
manuell an realer Hardware, Anlage blockiert
Mit SDAautomatisiert gegen virtuelle SPS bei jedem Commit
- /04Release & RollbackKlassisch
manuelles Aufspielen, kein definierter Rückweg
Mit SDAdeklarative CI/CD-Pipeline mit Quality Gates und Rollback
- /05NachvollziehbarkeitKlassisch
unklar, wer wann was geändert hat
Mit SDAlückenloser Audit-Trail für IEC 62443, NIS2, CRA
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. Wie eine strukturierte CI/CD-Implementierung diesen Zustand beendet, zeigt unser Leistungsüberblick.
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. Fachbegriffe wie „Audit-Trail“, „virtuelle SPS“ oder „CI/CD“ sind im Industrial-DevOps-Glossar erläutert.
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. Typische Herausforderungen für diesen Maschinentyp beschreibt unser Anwendungsfall Industrial DevOps für die Steuerungstechnik im Maschinenbau.
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)?
- Software Defined Automation (SDA) ist ein Ansatz, bei dem DevOps-Praktiken aus der Software-Entwicklung — Git-Versionierung, CI/CD-Pipelines, automatisierte Tests, Code Reviews — auf die SPS-Programmierung übertragen werden. Als Plattform kombiniert SDA Cloud-Engineering-Workspaces, Git-basierte Versionierung von SPS-Code, virtuelle SPS und CI/CD-Pipelines für Steuerungen von Siemens, Rockwell, Beckhoff, B&R und CODESYS.
- Q.02
- Wie unterscheidet sich SDA von klassischer SPS-Programmierung?
- Klassisch arbeiten SPS-Programmierer lokal im Engineering-Tool (z. B. TIA Portal), tauschen ZIP-Dateien per Mail und testen direkt an der Anlage. Mit SDA liegt der Code in Git-Repositories, Änderungen laufen über Pull Requests und Code Reviews, Builds und Tests passieren automatisiert gegen virtuelle SPS in einer CI/CD-Pipeline — bevor der Code auf reale Hardware kommt.
- Q.03
- Welche Vorteile bietet CI/CD für SPS-Entwicklung?
- CI/CD für SPS verkürzt die Lead Time für Änderungen deutlich (im Comquent-Pilot um ca. 40 %), reduziert Inbetriebnahme-Iterationen, fängt Integrationsfehler vor der Anlage ab, schafft einen lückenlosen Audit-Trail für Compliance (IEC 62443, NIS2, Cyber Resilience Act) und ermöglicht paralleles Arbeiten mehrerer Entwickler am selben Projekt.
- Q.04
- Kann man TIA Portal mit Git versionieren?
- Ja. TIA-Portal-Projekte lassen sich über Export-Mechanismen, Siemens Openness, Plattformen wie Software Defined Automation, tia-connect oder Copia Automation in Git-Repositories versionieren. Damit sind echte Branches, Pull Requests, Diff-Ansichten und automatisierte Builds für Siemens-SPS-Code möglich.
- Q.05
- Welche SPS-Hersteller unterstützt Software Defined Automation?
- Die SDA-Plattform unterstützt Siemens (TIA Portal bis v20, SIMATIC Manager 5.7, SIMATIC S7-1200/1500), Beckhoff TwinCAT 3.1, Rockwell Studio 5000 v37, B&R Automation Studio, CODESYS sowie SEW-EURODRIVE MOVITOOLS. Damit sind gemischte Steuerungslandschaften mit einem einheitlichen DevOps-Workflow betreibbar.
- Q.06
- Wie lange dauert ein SDA-Pilot?
- Ein fokussiertes SDA-Pilotprojekt mit einer Maschine oder Linie lässt sich in 6 bis 10 Wochen aufsetzen. Comquent arbeitet in vier Phasen: Discovery & Reifegrad (Woche 1–2), Pilot-Setup (Woche 3–5), CI/CD & virtuelle SPS (Woche 6–8), Roll-out & Enablement ab Woche 9.
- Q.07
- Ist SDA für Bestandsanlagen (Brownfield) geeignet?
- Ja. SDA kann bestehende SPS-Projekte aus TIA Portal, Studio 5000 oder TwinCAT importieren und versionieren, ohne dass die Anlage umgebaut werden muss. Der Einstieg erfolgt typischerweise über Backup- und Versionierungs-Funktionen; CI/CD und virtuelle Tests kommen anschließend schrittweise dazu.
- Q.08
- 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 TIA Portal, Studio 5000, TwinCAT oder CODESYS — SDA bringt Versionierung, Tests, Reviews und CI/CD darum herum.
- Q.09
- Welche Alternativen zur SDA-Plattform gibt es?
- Alternativen sind Copia Automation (Git-native, Multi-Vendor), tia-connect (Fokus CI/CD für TIA Portal), Siemens Industrial Edge (tief in die Siemens-Welt integriert) sowie Eigenbau-Ansätze mit Jenkins, GitLab CI oder Azure DevOps in Kombination mit Siemens Openness. Jede Option hat unterschiedliche Stärken hinsichtlich Vendor-Support, Betriebsmodell und Integrationsaufwand.
- Q.10
- Für welche Unternehmen lohnt sich SDA?
- SDA lohnt sich vor allem für Maschinen- und Anlagenbauer mit mehr als fünf SPS-Entwicklern, für Serienmaschinenbau mit häufigen Varianten und für Unternehmen mit Compliance-Anforderungen nach ISO 26262, IEC 62443, TISAX, NIS2 oder Cyber Resilience Act. Weniger geeignet ist SDA für Einzelanlagenbau mit sehr kleinen Teams oder reine Legacy-Umgebungen ohne Modernisierungsbudget.
- Q.11
- Unterstützt Comquent die Einführung von SDA?
- Ja. Comquent begleitet die Einführung von Software Defined Automation von der Reifegrad-Analyse über das Pilotprojekt bis zum produktiven Roll-out — inklusive Git-Strategie, CI/CD-Pipelines, Test-Automatisierung gegen virtuelle SPS 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