Software Defined
Automation
im Praxistest.
Software Defined Automation (SDA) holt Git, Code Reviews, Tests gegen virtuelle SPS und CI/CD-Pipelines in die Steuerungsentwicklung. Hier steht, was das im Alltag eines Automatisierungsteams ändert, was Siemens, Rockwell und Schneider jeweils darunter verstehen und welche Zahlen ein achtwöchiger Pilot bei einem Maschinenbauer geliefert hat.
AI
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
DevOps, CI/CD und Industrial Automation seit 2006.
Software Defined Automation (SDA), auf Deutsch softwaredefinierte Automatisierung, entkoppelt die Steuerungssoftware von der Hardware und überträgt DevOps-Praktiken auf die SPS-Programmierung. Dazu gehören 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 Pilot bei einem Maschinenbauer sank die Lead Time für SPS-Änderungen damit um 40 %.
Stand: 25. September 2026 · TIA Portal V21 · PLCSIM Advanced V8.0 · SIMATIC S7-1500V · IEC 61499 · IEC 62443
Ist Software-defined Automation bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
- /01Was SDA istGit, Pull Requests, Tests gegen virtuelle SPS und CI/CD-Pipelines für TIA Portal, Studio 5000, TwinCAT, B&R und CODESYS.
- /02Was der Pilot brachteLead Time für SPS-Änderungen von fünf auf drei Arbeitstage, Inbetriebnahme-Iterationen von sieben auf vier, jede Änderung mit Audit-Trail.
- /03Was die Hersteller meinenSiemens und Schneider zielen vor allem auf die Laufzeit, also virtuelle SPS und IEC 61499. Plattformen wie SDA setzen bei den Werkzeugen darüber an. Beides schließt sich nicht aus.
- /04Wie lange es dauertEin erster funktionierender Workflow steht nach sechs bis zehn Wochen, in vier Phasen.
- /05Woran es scheitertSelten am Werkzeug. Meist an Branching-Strategie, Review-Kultur und daran, dass IT und OT zu spät miteinander reden.
- /06Für wen es sich lohntMaschinen- und Anlagenbauer ab etwa fünf SPS-Entwicklern und alle, die Änderungen für IEC 62443, NIS2 oder den Cyber Resilience Act nachweisen müssen.
Was ist Software
Defined
Automation (SDA)?
Software Defined Automation (SDA), auf Deutsch softwaredefinierte Automatisierung, entkoppelt die Steuerungssoftware von der SPS-Hardware und überträgt DevOps-Praktiken auf die Steuerungsentwicklung: Git-Versionierung des SPS-Codes, Code Reviews per Pull Request, automatisierte Tests gegen virtuelle SPS und CI/CD-Pipelines. Der Ansatz arbeitet herstellerübergreifend, für Siemens TIA Portal, Rockwell Studio 5000, Beckhoff TwinCAT, B&R Automation Studio und CODESYS.
Der Begriff hat zwei Seiten. Als Konzept meint er die Entkopplung der Steuerungssoftware von der Hardware, auf der sie läuft. In der Praxis meint er, dass die Werkzeuge der Software-Entwicklung in der SPS-Programmierung ankommen: Branches statt ZIP-Ordner, Reviews statt Zuruf, Pipelines statt manueller Aufspiel-Routinen.
Als Plattform kombiniert Software Defined Automation Cloud-Engineering-Workspaces, ein Git-Backend, virtuelle Steuerungen und CI/CD. Das sind genau die Werkzeuge, die wir als Industrial-DevOps-Berater vorher mit Jenkins, Git, Siemens Openness und eigenen 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 legt denselben Code in Git, ersetzt mündliche Reviews durch Pull Requests und verlagert Tests von der realen Anlage in Pipelines gegen virtuelle SPS. Die fünf Unterschiede im Einzelnen:
- /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, oft 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
Welche Probleme löst
Software Defined Automation
im Alltag?
Softwaredefinierte Automatisierung setzt dort an, wo Steuerungsänderungen heute Zeit und Nachweise kosten: bei Tests, die erst an der Anlage stattfinden, bei Softwareständen, die niemand sicher zuordnen kann, und bei Freigaben, die nur mündlich existieren. Die Frage nach dem Werkzeug kommt danach.
Diese sechs Sätze fallen in unseren Erstgesprächen mit Maschinen- und Anlagenbauern so regelmäßig, dass wir sie inzwischen mitschreiben. In der mittleren Spalte steht, was der jeweilige Zustand im Betrieb kostet. Rechts steht, was ihn abstellt und wo im Artikel das genauer beschrieben ist.
Dass Steuerungscode heute auf Netzlaufwerken liegt, hat übrigens einen einfachen Grund. Die Engineering-Tools haben paralleles Arbeiten jahrelang nicht vorgesehen, und der ZIP-Ordner war die vernünftigste Antwort darauf.
Getestet wird erst an der Anlage
Jede Iteration bindet die Maschine und einen Inbetriebnehmer vor Ort. Im Pilot waren es sieben Iterationen je Release, und ein Schnittstellenfehler, den erst die Inbetriebnahme findet, kostet dort schnell einen halben Tag.
Ein Smoke-Test gegen eine virtuelle SPS bei jedem Pull Request. Er ersetzt die Inbetriebnahme nicht, fängt aber die Fehler ab, die man vorher hätte sehen können. Der erste rote Balken im Pilot
Vier Stände auf dem Netzlaufwerk, und keiner ist sicher der laufende
Solange der Kollege da ist, der die Anlage kennt, fällt das nicht auf. Geht er in Rente, lässt sich sein Wissen aus keinem Backup wiederherstellen. Genau so hat das Pilotprojekt in diesem Artikel angefangen.
Ein Repository je Maschine, ein regelmäßiger Abgleich zwischen dem Stand auf der Steuerung und dem Stand in Git, und Commit-Nachrichten, die das Warum festhalten. Git-Versionierung für SPS-Code
Siemens, Beckhoff und Rockwell, und für jeden läuft es anders
Jede Werkzeugwelt hat ihre eigene Backup-Routine, ihre eigene Ablage und ihren eigenen Experten. Wer das Team wechselt, lernt den Ablauf neu, und eine gemeinsame Freigabe über alle Steuerungen gibt es nicht.
Eine Schicht über den Engineering-Tools, die für alle Hersteller denselben Ablauf erzwingt: Commit, Review, Build, Test. Welche Plattformen das heute können, zeigt der Vergleich. Plattformen im Vergleich
Bis ein neuer Kollege loslegen kann, vergehen Tage
Die passende TIA-Portal-Version, Lizenzen, Add-ins, Hardware-Support-Pakete und für das ältere Projekt eine zweite Installation daneben. Das kostet Tage, bevor die erste Zeile Code entsteht, und es wiederholt sich bei jedem Laptopwechsel.
Browserbasierte Engineering-Workspaces, in denen die richtige Tool-Version schon installiert ist. Neue Teammitglieder arbeiten nach Stunden statt nach Tagen. Cloud Engineering Workspaces
Der Kunde fragt, welche Software in seiner Maschine steckt
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden, auch für Produkte, die schon im Feld sind. Wer den Softwarestand erst aus Mails und Seriennummern rekonstruieren muss, schafft diese Frist nicht.
Commit-Historie und Deployment-Protokoll je Maschine. Die Antwort liegt dann in Minuten vor, mit Autor, Datum und Freigabe. CRA-Fristen für den Maschinenbau
Die IT hat Git vorgeschlagen, und nach dem ersten Merge war Schluss
Git aus der IT eins zu eins übernommen scheitert an der binären Projektdatei. Der erste Konflikt lässt sich nicht auflösen, und danach gilt Versionierung für SPS-Code im Team als Theorie.
Eine Branching-Strategie, die zur Inbetriebnahme passt, und ein Quelltext-Export statt der Projektdatei. Das steht nicht zufällig an erster Stelle unserer Lessons Learned. Was wirklich gewirkt hat
Quelle der Auswahl: Erstgespräche und Einführungsprojekte bei Comquent. Die Meldefrist in Zeile /05 folgt aus Art. 14 des Cyber Resilience Act, Verordnung (EU) 2024/2847.
Was leistet Software
Defined Automation
konkret?
Software Defined Automation leistet in der Praxis sechs Dinge: browserbasierte Engineering-Workspaces, Git-Versionierung von SPS-Code, virtuelle SPS für automatisierte Tests, CI/CD-Pipelines für Steuerungsprojekte, einen lückenlosen Audit-Trail und einen herstellerübergreifenden Workflow. Die Bausteine lassen sich einzeln einführen, und meist beginnt es mit Versionierung und Backup.
- /01
Cloud Engineering Workspaces
Browserbasierte Engineering-Umgebung. Setup in Stunden, nicht Tagen.
Statt lokal installierter Engineering-Tools arbeiten SPS-Programmierer in browserbasierten Workspaces. Jeder Entwickler bekommt mit wenigen Klicks eine isolierte Umgebung mit der passenden Tool-Version. Die langen Setup-Tage entfallen, neue Teammitglieder sind nach Stunden arbeitsfähig.
- /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 liegen in Git-Repositories, mit echten Branches, Pull Requests und Code Reviews. Änderungen lassen sich nachvollziehen, vergleichen und kontrolliert zusammenführen.
- /03
Virtuelle SPS für Tests und Simulation
CI/CD ohne reale Hardware. Regressionstests bei jedem Commit.
Virtuelle SPS fahren in der CI/CD-Pipeline hoch, im Siemens-Umfeld meist S7-PLCSIM Advanced, aktuell Version 8.0 zu TIA Portal V21. Tests laufen ohne reale Hardware, niemand blockiert mehr eine Produktionsanlage, und Regressionstests laufen bei jedem Commit. Das ist noch keine virtuelle Inbetriebnahme mit vollständigem Anlagenmodell, aber der Teil davon, der sich bei jeder Änderung wiederholen lässt.
- /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 in Richtung Anlage geht.
- /05
Audit-Trail und Compliance
Wer hat wann welchen Funktionsbaustein geändert?
SDA liefert lückenlose Audit-Logs und Approval-Workflows. Das ist eine harte Anforderung für regulierte Branchen, für IEC 62443 und für den Cyber Resilience Act.
- /06
Herstellerübergreifender Ablauf
Ein Workflow für gemischte Steuerungslandschaften.
SDA versteht sich als Schicht über den Engineering-Tools der Hersteller. Laut Herstellerdokumentation deckt die Plattform neben Siemens bis TIA Portal V21, Rockwell, Beckhoff, B&R und CODESYS inzwischen auch Mitsubishi, Bosch Rexroth ctrlX, KUKA und SEW ab. Wie weit die Pipeline-Funktionen je Hersteller reichen, ist unterschiedlich, und genau das gehört in jede Evaluierung.
Welche Vorteile bietet
softwaredefinierte Automatisierung?
Softwaredefinierte Automatisierung zahlt sich an vier Stellen aus. Änderungen laufen schneller durch, weil Build und Test automatisiert ablaufen. Gemischte Steuerungslandschaften lassen sich mit einem einzigen Workflow betreiben. IT und OT arbeiten mit denselben Werkzeugen. Und jede Änderung ist nachweisbar. Im Pilot bei einem Maschinenbauer sank die Lead Time von fünf auf drei Arbeitstage, die Inbetriebnahme-Iterationen je Release von sieben auf vier.
Der Reihe nach, und mit den Zahlen aus dem Pilot statt aus dem Prospekt. Die vierte Zeile ist dabei die, die in Projekten am häufigsten den Ausschlag gibt, obwohl sie in Vorträgen zuletzt genannt wird.
- /01Änderungen laufen schneller durch
Build, statische Analyse und Test passieren automatisiert.
Weil jeder Commit gebaut, statisch geprüft und gegen eine virtuelle SPS getestet wird, fällt der manuelle Umlauf zwischen Programmierung und Anlage weg. Im Pilot sank die Lead Time für eine SPS-Änderung von rund fünf auf drei Arbeitstage, die Inbetriebnahme-Iterationen je Release von sieben auf vier.
- /02Weniger Bindung an einen Steuerungshersteller
Ein Workflow für Siemens, Rockwell und Beckhoff zugleich.
Versionierung, Reviews und Pipelines funktionieren über die Engineering-Tools mehrerer Hersteller hinweg. Der Vendor Lock-in lockert sich damit auf der Werkzeugebene. Portabel wird die Applikation dadurch nicht, das entscheidet die Laufzeitumgebung und damit die Frage nach offener softwaredefinierter Automatisierung nach IEC 61499.
- /03IT und OT arbeiten mit denselben Mitteln
Git, Pull Requests und Pipelines auf beiden Seiten.
Automatisierung, IT-Betrieb und Security sehen dieselben Repositories, dieselben Änderungen und dieselben Testergebnisse. Im Pilot wurde daraus ein Nebeneffekt, mit dem niemand gerechnet hatte: Erfahrene Programmierer gaben ihr Wissen über Review-Kommentare weiter, statt es im Kopf zu behalten.
- /04Jede Änderung ist nachweisbar
Wer, wann, was, freigegeben von wem.
Commit-Historie und Approval-Workflow beantworten die Auditor-Frage ohne Suche im Netzlaufwerk. Im Pilot lagen nach sechs Monaten 100 % der Änderungen mit Audit-Trail vor, eine Anforderung, die IEC 62443, NIS2 und der Cyber Resilience Act ohnehin stellen.
Quelle: Comquent SDA-Pilot 2025/2026, Messzeitraum 6 Monate nach Go-live.
Was verstehen Siemens,
Rockwell und Schneider
unter SDA?
Alle drei meinen die Entkopplung der Steuerungssoftware von der Hardware, setzen aber auf verschiedenen Ebenen an. Siemens virtualisiert die Steuerung selbst mit der SIMATIC S7-1500V auf Industrial Edge. Rockwell betont Cloud-Engineering, Emulation und virtuelle Inbetriebnahme. Schneider Electric setzt auf eine herstellerübergreifende Laufzeit nach IEC 61499.
Für Sie als Anwender ist die Ebene wichtiger als der Begriff. Git, Reviews und Pipelines lassen sich einführen, ohne an der laufenden Anlage etwas zu ändern. Eine virtuelle SPS oder eine offene Runtime dagegen ist eine Investitionsentscheidung, die Hardware, Zertifizierung und Wartung betrifft.
- Ebene 03Werkzeuge
Git, Pull Requests, CI/CD-Pipelines und Tests gegen virtuelle SPS, über den Engineering-Tools der Hersteller.
SDA-Plattform, Copia, tia-connect, Jenkins mit Openness
ohne Eingriff in die Anlage
- Ebene 02Laufzeit
Die Steuerungslogik läuft als Software auf Standard-Hardware oder auf einer herstellerübergreifenden Runtime.
SIMATIC S7-1500V, EcoStruxure Automation Expert, IEC 61499
Investitionsentscheidung
- Ebene 01Hardware
Steuerungen, E/A, Antriebe, Industrie-PCs und Edge-Server im Schaltschrank.
S7-1500, ControlLogix, Beckhoff-IPC, Edge-Server
bleibt, wird austauschbarer
Von oben nach unten gelesen: in dieser Reihenfolge gehen die meisten Projekte die Ebenen an.
- /01
Siemens
Die Steuerung selbst wird zur Software.
Unter dem Dach von Industrial Operations X fasst Siemens Industrial Edge, die virtuelle Steuerung SIMATIC S7-1500V, WinCC Unified und die auf Visual Studio Code aufbauende Engineering-Umgebung SIMATIC AX zusammen. Die S7-1500V gibt es seit 2023. 2025 kam mit der S7-1500V F eine fehlersichere Variante dazu, mit TÜV-Zulassung nach IEC 61508 für Anwendungen bis SIL 3 beziehungsweise PL e. Siemens nennt sie die erste fehlersichere virtuelle SPS am Markt.
Quelle: Siemens Blog, Mai 2025 - /02
Rockwell Automation
Engineering und Inbetriebnahme wandern in Software.
Rockwell beschreibt SDA als Entkopplung der Steuerungssoftware von der Automatisierungshardware und nennt dafür vor allem Werkzeuge: FactoryTalk Design Studio für cloudbasiertes Engineering, FactoryTalk Logix Echo zur Emulation von ControlLogix-Steuerungen und Emulate3D für digitale Zwillinge. Das Versprechen sind kürzere Inbetriebnahmen durch virtuelle Validierung.
Quelle: rockwellautomation.com - /03
Schneider Electric
Die Laufzeit soll keinem Hersteller allein gehören.
EcoStruxure Automation Expert baut auf IEC 61499 und der gemeinsam getragenen Runtime von UniversalAutomation.org auf. Im Juni 2026 hat Schneider zusammen mit HPE ein Modernisierungsangebot als Service vorgestellt, bei dem virtuelle Steuerungen neben bestehenden SPS- und Leitsystemen laufen, ohne dass die Altanlage vorher ersetzt werden muss.
Quelle: Schneider Electric, 23.06.2026 - /04
SDA GmbH und SEW-EURODRIVE
Eine Werkzeugschicht über allen Herstellern.
Die Plattform der Software Defined Automation GmbH lässt die Laufzeit unangetastet. Sie bündelt Engineering-Workspaces, Versionierung, Backup und Deployment über die Tools der Hersteller. SEW-EURODRIVE hat sie im Dezember 2025 gemeinsam mit SDA als OrchestrationSuite eingeführt und auf der Interpack 2026 eine KI-gestützte SPS-Code-Generierung aus Funktionsbeschreibungen in natürlicher Sprache live gezeigt.
Quelle: SEW-EURODRIVE, 06.05.2026
Ein Argument aus den Herstellerbroschüren gilt nur für eine Ebene. Mehr Ausfallsicherheit bei Lieferengpässen bringt erst die virtuelle Steuerung, weil die Logik dann auf Standard-Servern läuft. Git und Pipelines machen Änderungen sicherer, aber eine defekte CPU braucht danach trotzdem dieselbe Ersatz-CPU wie vorher.
Was ist offene
softwaredefinierte Automatisierung?
Offene softwaredefinierte Automatisierung trennt die Steuerungslogik von der Hardware und verlangt zusätzlich Portabilität und Interoperabilität. Dieselbe Applikation soll auf Steuerungen unterschiedlicher Hersteller lauffähig bleiben. Ihre drei Kernmerkmale sind die Entkopplung von Software und Hardware, die Hersteller-Offenheit der Laufzeitumgebung und die Integration von IT- und OT-Werkzeugen. Technische Grundlage ist die IEC 61499 zusammen mit der gemeinsam getragenen Runtime von UniversalAutomation.org, kommerziell umgesetzt etwa in Schneider Electrics EcoStruxure Automation Expert. Von SDA-Plattformen unterscheidet sie sich durch die Ebene. Offenheit ist eine Entscheidung über die Laufzeitumgebung, SDA-Plattformen setzen mit Git, Reviews und CI/CD darüber an.
Entkoppelt sind beide. Offen ist die Automatisierung erst, wenn die entkoppelte Applikation auch auf der Steuerung eines anderen Herstellers läuft. In der Praxis kommt fast immer die Werkzeugebene zuerst. Sie funktioniert ohne Eingriff in laufende Anlagen, während der Wechsel der Runtime eine Investitionsentscheidung ist, die kein Team nebenbei trifft. Wie das für bestehende Steuerungslandschaften aussieht, beschreibt unser Artikel zur Versionsverwaltung für Steuerungscode.
- /01Entkopplung
Die Applikation hängt nicht mehr an einem Steuerungstyp.
Die Steuerungslogik läuft als Software-Artefakt, nicht als fest verdrahtetes Abbild einer bestimmten CPU. Erst dadurch lässt sich dieselbe Applikation versionieren, simulieren und auf unterschiedliche Ziele ausrollen.
- /02Hersteller-Offenheit
IEC 61499 und eine gemeinsam getragene Laufzeitumgebung.
Die IEC 61499 beschreibt verteilte Automatisierungsapplikationen aus portablen Funktionsbausteinen. UniversalAutomation.org stellt dazu eine gemeinsam getragene Runtime bereit, die mehrere Hersteller in ihren Produkten implementieren, kommerziell etwa Schneider Electric mit EcoStruxure Automation Expert.
- /03IT-/OT-Integration
Dieselben Werkzeuge wie in der Software-Entwicklung.
Versionskontrolle, Build-Server, automatisierte Tests und Rollback-Mechanismen greifen auf die Automatisierungsapplikation zu. Genau hier setzen SDA-Plattformen an, und zwar unabhängig davon, ob die Runtime darunter offen oder herstellergebunden ist.
Welche SDA-Plattformen
gibt es?
„Software Defined Automation“ ist ein Konzept und zugleich ein Produkt der Software Defined Automation GmbH aus Garching. Daneben gibt es weitere Plattformen. Die einen bringen CI/CD über die bestehenden Engineering-Tools, die anderen virtualisieren die Steuerung oder öffnen die Laufzeitumgebung darunter. Die letzte Zeile gehört bewusst in die zweite Gruppe.
| Plattform | SPS-Support | Deployment | Stärke |
|---|---|---|---|
| SDA Platform | Siemens, Rockwell, Beckhoff, B&R, CODESYS, Mitsubishi, SEW u. a. | Cloud / Hybrid | Multi-Vendor, Backup und Deployment, KI-Funktionen |
| 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 + S7-1500V | nur Siemens | On-Prem / Edge | Virtuelle SPS im Betrieb, fehlersicher bis SIL 3 (S7-1500V F) |
| Rockwell FactoryTalk Design Studio + Logix Echo | Rockwell Logix | Cloud / PC | Cloud-Engineering und Emulation für Logix |
| Eigenbau (Jenkins + Git + Openness) | alle | On-Prem | Volle Kontrolle, hoher Betriebsaufwand |
| EcoStruxure Automation Expert | IEC-61499-Runtime, herstellerübergreifend | On-Prem / Edge | Offene Laufzeitumgebung (UniversalAutomation.org), andere Ebene als CI/CD |
Vergleich: Comquent Research, Stand September 2026, basierend auf öffentlich verfügbaren Produktinformationen der Hersteller.
Wie lief der SDA-Pilot
bei einem
Maschinenbauer?
Unser Pilotkunde ist ein mittelständischer Maschinenbauer aus Süddeutschland mit rund 180 Mitarbeitern und einem zwölfköpfigen Automatisierungsteam. Gearbeitet wird überwiegend mit Siemens TIA Portal auf 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 dem Pilot lief TIA Portal lokal auf den Notebooks, Backups lagen auf dem Netzlaufwerk, und jede Änderung ging von Hand direkt an die Anlage. Versionsstände gab es, irgendwo. Als ein langjähriger Programmierer in den Ruhestand ging, wusste niemand mehr, welcher der vier Stände auf dem Netzlaufwerk der laufende war. Sein Wissen ließ sich aus keinem Backup wiederherstellen. Getestet wurde von Hand, Reviews fanden mündlich am Schaltschrank statt.
- 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
In acht Wochen stand ein erster Workflow: Repository-Struktur in SDA, eine definierte Branching-Strategie, automatisierter Build, statische Analyse und ein Smoke-Test gegen eine virtuelle SPS bei jedem Pull Request.
AIEine Stufe der Pipeline schlägt an, weil ein anderes Modul noch die alte Schnittstelle erwartet. An der Werkbank kostet das einen Blick auf den Diff, bei der Inbetriebnahme einen halben Tag.
Im zweiten Sprint kam der erste Aha-Moment. Ein Programmierer hatte einen Funktionsbaustein „gerade mal eben“ umgebaut, und die Pipeline wurde rot, weil ein anderes Modul die alte Schnittstelle erwartete. Ohne Pipeline hätte genau dieser Fehler bei der Inbetriebnahme einen halben Tag gekostet. Seit diesem roten Balken fragt im Team niemand mehr, ob die Pipeline nötig ist. Sie hat einen halben Inbetriebnahmetag gespart, bevor jemand ihn verloren hatte.
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. Zum ersten Mal hatten Geschäftsführung und Instandhaltung außerdem 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.
Wie führt man SDA
in vier Phasen ein?
Mit einer Linie, einem Team und einem messbaren Ziel. Die vier Phasen unten sind der Weg, den auch der Pilot gegangen ist. Nach Woche 8 steht ein funktionierender Workflow, ab Woche 9 geht es in die Breite.
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.
Wo steht Ihr Team heute?
Der Reifegrad-Check stellt zehn Fragen zu Pipeline, Automatisierungsgrad, Tests, Deployment-Frequenz und Teamkultur. Danach sehen Sie Ihren Score und die drei Stellen, an denen sich der Einstieg am ehesten lohnt. Eine Anmeldung braucht es dafür nicht.
Reifegrad-Check starten10 Fragen · rund 3 Minuten · ohne Anmeldung
Was hat im Pilot
wirklich gewirkt?
- /01Über den Erfolg entscheidet weniger das Werkzeug als die Branching-Strategie und die Review-Kultur. Wer Git aus der IT eins zu eins in die OT überträgt, scheitert am ersten Merge.
- /02Virtuelle SPS machen Regressionstests überhaupt erst bezahlbar, 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.
- /04Binden Sie IT-Security und Netzwerkverantwortliche früh ein, vor allem 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, kommen weitere Anlagen dazu.
- /06Messen Sie die Wirkung früh: Lead Time für Änderungen, Anzahl der 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.
Begriff und Abgrenzung
- Was ist Software Defined Automation (SDA)?
- Software Defined Automation (SDA), auf Deutsch softwaredefinierte Automatisierung, entkoppelt die Steuerungssoftware von der Hardware und überträgt Praktiken aus der Software-Entwicklung auf die SPS-Programmierung: Git-Versionierung, CI/CD-Pipelines, automatisierte Tests und Code Reviews. 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, CODESYS und weiteren Herstellern.
- Wofür steht die Abkürzung SDA?
- In der Automatisierungstechnik steht SDA für Software Defined Automation, auf Deutsch softwaredefinierte Automatisierung: Die Steuerungssoftware wird von der SPS-Hardware entkoppelt und wie Software versioniert, getestet und ausgerollt. Dieselbe Abkürzung trägt die Software Defined Automation GmbH aus Garching bei München, deren Plattform genau diesen Ansatz umsetzt. Außerhalb der Industrie ist SDA anders belegt, etwa für die Schweizer Nachrichtenagentur Keystone-SDA oder für die Datenleitung SDA (Serial Data) im I²C-Bus.
- Wie definiert Siemens softwaredefinierte Automatisierung?
- Siemens versteht unter softwaredefinierter Automatisierung, bewährte Methoden der Software-Entwicklung wie IT-ähnliche Update- und Verwaltungsmechanismen auf die Betriebstechnik zu übertragen. Technisch gehören dazu Industrial Edge, die virtuelle Steuerung SIMATIC S7-1500V, WinCC Unified und die Engineering-Umgebung SIMATIC AX, zusammengefasst unter Industrial Operations X. Die fehlersichere Variante S7-1500V F hat eine TÜV-Zulassung nach IEC 61508 für Anwendungen bis SIL 3 beziehungsweise PL e.
- Was ist offene softwaredefinierte Automatisierung?
- Offene softwaredefinierte Automatisierung trennt die Steuerungslogik von der Hardware und verlangt zusätzlich Portabilität und Interoperabilität. Dieselbe Applikation soll auf Steuerungen unterschiedlicher Hersteller lauffähig bleiben. Ihre drei Kernmerkmale sind die Entkopplung von Software und Hardware, die Hersteller-Offenheit der Laufzeitumgebung und die Integration von IT- und OT-Werkzeugen. Technische Grundlage ist die IEC 61499 zusammen mit der gemeinsam getragenen Runtime von UniversalAutomation.org, kommerziell umgesetzt etwa in Schneider Electrics EcoStruxure Automation Expert. SDA-Plattformen setzen eine Ebene höher an: Sie bringen Git, Reviews und CI/CD über die bestehenden Engineering-Tools, ohne die Laufzeitumgebung auszutauschen.
- Welche Arten der Automatisierung gibt es?
- In der Steuerungstechnik lassen sich drei Ansätze unterscheiden: die klassische hardwaregebundene Automatisierung, bei der die Applikation an die SPS eines bestimmten Herstellers gebunden ist; die softwaredefinierte Automatisierung, bei der die Steuerungslogik von der Hardware entkoppelt und wie Software versioniert, getestet und ausgerollt wird; und die offene softwaredefinierte Automatisierung, die zusätzlich die Portierbarkeit zwischen Herstellern nach IEC 61499 vorsieht. Davon abzugrenzen ist RPA (Robotic Process Automation). Sie automatisiert Büroprozesse in der IT, nicht die Steuerung von Maschinen und Anlagen.
- Was ist industrielle Automatisierung?
- Industrielle Automatisierung bezeichnet die selbsttätige Steuerung von Maschinen, Anlagen und Fertigungsprozessen, technisch getragen von speicherprogrammierbaren Steuerungen (SPS), Sensoren, Aktoren und übergeordneten Systemen wie SCADA oder MES. Ziel ist, dass eine Anlage ohne manuellen Eingriff im geforderten Takt und in gleichbleibender Qualität produziert. Software Defined Automation ändert daran nicht, was gesteuert wird, sondern wie die Steuerungssoftware entsteht: entkoppelt von der Hardware, versioniert in Git, getestet gegen virtuelle SPS.
- Was ist der Unterschied zwischen Automatisierung und Digitalisierung?
- Automatisierung lässt einen Vorgang ohne menschlichen Eingriff ablaufen, etwa eine SPS, die eine Achse taktet und eine Temperatur regelt. Digitalisierung überführt Informationen und Abläufe in eine digitale Form, damit sie auswertbar und verknüpfbar werden. In der Fertigung greifen beide ineinander. Die Anlage automatisiert den Prozess, die Digitalisierung macht auswertbar, was dabei passiert. Softwaredefinierte Automatisierung sitzt an der Nahtstelle, weil sie die Steuerungssoftware selbst zu einem digitalen, versionierten Artefakt macht. Wer wann welche Änderung an welcher Maschine vorgenommen hat, steht dann in Git und nicht im Gedächtnis eines Kollegen.
- Was sind softwaredefinierte Fahrzeuge, und was haben sie mit softwaredefinierter Automatisierung zu tun?
- Ein softwaredefiniertes Fahrzeug (Software Defined Vehicle, SDV) ist ein Auto, dessen Funktionen überwiegend in Software liegen und per Update nachgeliefert werden, statt fest in einzelnen Steuergeräten zu stecken. Das zugrunde liegende Prinzip ist dasselbe wie bei der softwaredefinierten Automatisierung. Die Funktion wird von der Hardware entkoppelt, damit sie versioniert, getestet und kontrolliert ausgerollt werden kann. Unterschiedlich ist das Feld. Das SDV betrifft das Produkt Fahrzeug, softwaredefinierte Automatisierung die Steuerung von Maschinen und Anlagen in der Produktion. Automobilzulieferer begegnen beidem gleichzeitig, weil ihre Produkte in Richtung SDV wandern, während ihre Fertigungslinien noch über Netzlaufwerke versioniert werden.
- Was ist die Software Defined Automation GmbH?
- Die Software Defined Automation GmbH ist ein Software-Unternehmen aus Garching bei München, dessen gleichnamige Plattform Cloud-Engineering-Workspaces, Git-Versionierung, virtuelle SPS und CI/CD für Steuerungscode bündelt. SEW-EURODRIVE vertreibt die Plattform als OrchestrationSuite. Der Begriff „Software Defined Automation“ bezeichnet daneben das allgemeine Konzept, und Siemens, Rockwell und Schneider Electric verwenden ihn für ihre jeweils eigenen Ansätze. Comquent ist ein unabhängiges Beratungshaus und arbeitet plattformübergreifend. Welche Plattform passt, entscheidet die vorhandene Steuerungslandschaft, nicht der Anbieter.
Technik und Werkzeuge
- 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.
- Was ist eine virtuelle SPS?
- Eine virtuelle SPS ist eine Steuerung, deren Laufzeit als Software auf Standard-Hardware läuft, etwa auf einem Industrie-PC oder Edge-Server, statt auf einer eigenen CPU-Baugruppe. Für automatisierte Tests in einer CI/CD-Pipeline genügt meist eine Simulation wie S7-PLCSIM Advanced, aktuell in Version 8.0 zu TIA Portal V21. Für den produktiven Betrieb gibt es virtuelle Steuerungen wie die SIMATIC S7-1500V, die auf Industrial Edge läuft und als S7-1500V F auch fehlersicher verfügbar ist.
- Kann man TIA Portal mit Git versionieren?
- Ja. Seit V18 bringt das TIA Portal ein integriertes Version Control Interface mit, das Bausteine als Quelltext exportiert, ab V21 auch als lesbares LAD, FBD und SCL. Daneben lassen sich TIA-Portal-Projekte über 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.
- Welche SPS-Hersteller unterstützt Software Defined Automation?
- Laut Herstellerdokumentation unterstützt die SDA-Plattform Siemens vom SIMATIC Manager 5.7 bis TIA Portal V21, Rockwell bis Studio 5000 V37, Beckhoff TwinCAT 3.1, B&R Automation Studio, CODESYS V3.5, Mitsubishi GX Works 2 und 3 sowie SEW-EURODRIVE MOVISUITE. Dazu kommen Bosch Rexroth ctrlX, Schneider EcoStruxure, KUKA WorkVisual, COPA-DATA zenon und Wago. Welche Pipeline-Schritte je Hersteller verfügbar sind, unterscheidet sich; das gehört in jede Evaluierung.
- Ersetzt SDA Tools wie TIA Portal oder Studio 5000?
- Nein. SDA versteht sich als Schicht ü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.
- 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 mit der virtuellen Steuerung S7-1500V (tief in die Siemens-Welt integriert), Rockwell FactoryTalk Design Studio mit Logix Echo für Rockwell-Steuerungen sowie Eigenbau-Ansätze mit Jenkins, GitLab CI oder Azure DevOps in Kombination mit Siemens Openness. Jede Option hat unterschiedliche Stärken bei Hersteller-Unterstützung, Betriebsmodell und Integrationsaufwand.
Nutzen und Einführung
- Welche Vorteile bietet softwaredefinierte Automatisierung?
- Softwaredefinierte Automatisierung zahlt sich an vier Stellen aus. Änderungen laufen schneller durch, weil Build, statische Analyse und Test automatisiert ablaufen. Gemischte Steuerungslandschaften lassen sich mit einem einzigen Workflow betreiben, was den Vendor Lock-in auf der Werkzeugebene lockert. IT und OT arbeiten mit denselben Mitteln, also Git, Reviews und Pipelines. Und jede Änderung ist nachweisbar, was IEC 62443, NIS2 und der Cyber Resilience Act ohnehin verlangen. Im Comquent-Pilot bei einem Maschinenbauer sank die Lead Time für SPS-Änderungen von fünf auf drei Arbeitstage, die Inbetriebnahme-Iterationen je Release von sieben auf vier.
- 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.
- 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 und Reifegrad (Woche 1–2), Pilot-Setup (Woche 3–5), CI/CD und virtuelle SPS (Woche 6–8), Roll-out und Enablement ab Woche 9.
- 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.
- 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.
- 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.
Wie geht es bei Ihnen mit der SDA-Einführung weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
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.
Bringen Sie ins Erstgespräch die Zeile aus der Symptom-Tabelle mit, die bei Ihnen am meisten kostet. Daran klären wir in 30 Minuten, ob ein Pilot an einer Linie sinnvoll ist, welche Ebene zuerst drankommt und woran Sie nach acht Wochen messen, ob es sich gelohnt hat.
Ob Ihr Haus zu den Konstellationen gehört, in denen sich der Umbau rechnet, lässt sich auch vorher prüfen. Vier Herstellerprofile vom Sondermaschinenbau bis zum Gerätebau, sechs Signale samt ihren Kosten und drei Gründe, aus denen wir ein Mandat ablehnen, stehen unter Für wen wir arbeiten.
30 Minuten · unverbindlich · kein Vertriebsgespräch
Erstgespräch.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance