SPS Versionsverwaltung
in der Industrial IT.
Der Wandel kommt jetzt.
PLC-Programmierer sichern Code seit Jahrzehnten mit Kopieren, Einfügen, Umbenennen. Die Industrie zahlt einen hohen Preis. Ein Blick auf Zahlen, Ursachen und den Weg nach vorne.
AI
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
DevOps, CI/CD und Industrial Automation seit 2006.
Versionsverwaltung
für SPS.
Betriebshygiene.
SPS Versionsverwaltung (PLC Version Control) bezeichnet die systematische Erfassung, Nachverfolgung und Verwaltung von Änderungen an SPS-Programmen, HMI-Projekten, SCADA-Konfigurationen und anderen OT-Softwareständen. Etabliert sind drei Wege: OT-Speziallösungen wie octoplant (AMDT, ehemals versiondog) und Copia Automation, native Hersteller-Integrationen wie TIA Portal V21 (VCI) oder Beckhoff TwinCAT 3, dazu Open-Source Git über Gitea oder GitLab On-Premise für Air-Gap-Netze.
Während in der klassischen Softwareentwicklung Git mit über 80 % Marktanteil Standard ist, dominiert in der Operational Technology noch immer manuelle Copy-Paste-Versionierung. Diese Lücke ist kein technisches Detail. Sie ist ein Betriebsrisiko und eine Compliance-Luecke (IEC 62443).
Der IT/OT-Convergence-Markt wächst mit 12,6 % CAGR auf über 100 Milliarden Dollar bis 2030.
In der Softwareentwicklung ist Git seit Jahren Standard, mit über 80 % Marktanteil und rund 100 Millionen aktiven Nutzern weltweit. In der Operational Technology dominiert noch immer ein Workflow aus den 1990ern: Der SPS-Programmierer speichert sein Projekt als Anlage_V3_final_NEU2.zip auf einem Netzlaufwerk.
Falls Sie dieses Netzlaufwerk kennen: Der Ordner ist meist so alt wie die Anlage. Er ist so gewachsen, weil die Engineering-Werkzeuge dreißig Jahre lang nichts anderes hergaben. Niemand hat sich für Copy-Paste entschieden. Es war der einzige Weg, ein Binärformat zu sichern.
Seit Ende 2025 hat sich beides geändert. TIA Portal V21 exportiert Steuerungscode erstmals als diff-fähigen Text, und versiondog, jahrelang die Standardantwort in der Automatisierungstechnik, hat sein End-of-Life hinter sich. Dieser Artikel beginnt deshalb nicht bei den Werkzeugen, sondern bei den fünf Sätzen, an denen fehlende Versionsverwaltung im Werk tatsächlich auffällt, und rechnet vor, was jeder davon kostet. Danach folgen Tool-Vergleich, IEC-62443-Anforderungen und ein Einstieg in fünf Schritten.
Ist SPS-Versionsverwaltung 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.
Fünf Sätze.
Jeder davon
kostet Geld.
Fehlende SPS-Versionsverwaltung fällt selten als eigenes Thema auf. Sie zeigt sich als Satz in der Frühschicht, als Frage im Audit, als Nachtschicht, die länger dauert als geplant. Die fünf unten hören wir in Werken am häufigsten.
Neben jedem steht, was er in Stunden oder Euro bedeutet. Die Beträge sind Modellannahmen für eine mittelständische Linie, hergeleitet im Beitrag zu den Kosten von Maschinenstillstand. Setzen Sie Ihre eigenen Zahlen ein, die Größenordnung bleibt.
- /01Ausfall
„Welches Backup ist das richtige?“
Die Linie steht, und auf dem Netzlaufwerk liegen fünf ZIP-Stände mit fast gleichem Namen. Niemand kann sagen, welcher zuletzt auf der Steuerung lief, also wird der Stand aus dem Kopf rekonstruiert statt zurückgespielt.
Was es kostetAus einer Stunde Wiederinbetriebnahme werden vier. Bei 15.000 € Stillstandskosten je Stunde sind das 45.000 € pro Vorfall, die nicht an der Maschine entstehen, sondern an der Suche.
Was es auflöstEin Repository kennt genau einen aktuellen Stand je Anlage. Rückrollen heißt auschecken und laden, nicht rekonstruieren.
- /02Wissen
„Das weiß nur der Kollege, und der ist im Urlaub.“
Der Änderungsverlauf einer Anlage existiert nur als Erinnerung einer einzigen Person. Warum Baustein 47 vor zwei Jahren umgebaut wurde, steht nirgends.
Was es kostetJede Änderung an dieser Anlage wartet auf einen Menschen. Bei Urlaub, Krankheit oder Kündigung wandert das Wissen mit, und der Nachfolger beginnt beim Reverse Engineering.
Was es auflöstEine Commit-Message beantwortet die Warum-Frage dort, wo die Änderung liegt. Das Wissen bleibt an der Anlage, nicht an der Person.
- /03Drift
„Läuft auf der Anlage wirklich das, was im Ordner liegt?“
Der Stand auf der Steuerung und der Stand im Archiv laufen auseinander, weil eine Hotline-Änderung nachts direkt am Gerät gemacht und nie zurückgesichert wurde.
Was es kostetDer nächste geplante Rollout verteilt den Archivstand auf die Anlage und überschreibt die Korrektur. Der Fehler von damals ist wieder da, und diesmal sucht ihn niemand an dieser Stelle.
Was es auflöstEin automatischer Abgleich zwischen Gerät und Repository meldet die Abweichung am nächsten Morgen, nicht beim übernächsten Rollout.
- /04Nachweis
„Wer hat das wann freigegeben?“
Im Audit fragt der Prüfer nach dem Änderungsnachweis für einen sicherheitsrelevanten Baustein. Was vorliegt, ist eine Datei mit Zeitstempel und ein Name im Dateinamen.
Was es kostetDer Nachweis nach IEC 62443 SR 7.6 gilt als nicht erbracht. Was folgt, ist eine Feststellung und Nacharbeit unter Termindruck, meist kurz vor dem nächsten Audit.
Was es auflöstCommit-Historie plus Pull-Request-Freigabe sind der Nachweis. Wer, wann, was und wer freigegeben hat, steht als Datensatz da und nicht als Erinnerung.
- /05Lizenz
„Unser versiondog läuft doch noch.“
Das Archiv arbeitet weiter, die Backups laufen. Seit dem 31. Dezember 2025 gibt es für versiondog und AutoSave aber weder Support noch Code-Arbeit, und neue Geräte oder Editor-Versionen werden nicht mehr angebunden.
Was es kostetEine zentrale OT-Anwendung läuft ohne Patch-Pfad. Jede neue Steuerung und jedes Editor-Update vergrößert die Lücke zwischen Anlagenbestand und dem, was das Archiv noch lesen kann.
Was es auflöstDie Migration ist ohnehin fällig. Die offene Frage ist nur, ob sie auf octoplant führt oder auf einen Git-Pfad, und diese Frage beantwortet man besser vor der nächsten Erweiterung als danach.
Wer zwei oder drei dieser Sätze wiedererkennt, arbeitet in einer Anlagenlandschaft, die schneller gewachsen ist als die Ablage dahinter. Das ist der Zustand, in dem die meisten Werke sind, die uns anrufen.
Welcher der fünf bei Ihnen am teuersten ist, lässt sich vorab abschätzen. Der DevOps-Reifegrad-Check fragt genau diese Punkte ab.
3 Minuten · ohne Anmeldung · Ergebnis sofort
Ordnerwirrwarr
vs. Git-Workflow.
Alle fünf Sätze haben dieselbe Ursache. Ein Ordner kennt keine Historie, er kennt nur Dateien. Wer etwas anderes von ihm erwartet, etwa wer wann welche Zeile geändert hat, bekommt eine Antwort aus dem Gedächtnis. Was sich ändert, sobald ein Repository an seine Stelle tritt, steht hier nebeneinander.
- /01Manuelle Copy-Paste-Rename-Versionierung
- /02Kein Audit-Trail: wer hat was wann geändert?
- /03Gerätestatus ungleich Archivstatus, kein Abgleich
- /04Binäre PLC-Dateien nicht diff-fähig
- /05Kein Review-Prozess, keine Freigabe-Workflows
- /06Paralleles Arbeiten führt zu Überschreibungen
- /07Katastrophale Recovery-Zeiten bei Maschinenausfall
- /01Vollständige Änderungshistorie mit Kontext
- /02Commit-Messages: Wer, wann, warum
- /03Automatischer Abgleich: Gerät vs. Repository
- /04Visuelle Diff-Ansicht für Ladder Logic & FBD
- /05Pull-Request-Prozess mit Vier-Augen-Prinzip
- /06Branching: parallele Entwicklung ohne Konflikte
- /07Rollback auf jeden Gutzustand in Sekunden
Das ist keine akademische Betrachtung. Laut einer Analyse von Control Engineering ist der häufigste Grund für verlängerte Ausfallzeiten nach einem Maschinenfehler nicht die Hardware. Es ist die Suche nach dem korrekten Backup. Die Maschine wäre also schneller wieder gelaufen, aber niemand wusste, womit. Schmerzpunkt /01, in Euro.
Was die Suche pro Jahr kostet
Eine mittelständische Linie, zwei softwarebedingte Stillstände im Jahr, 15.000 € Deckungsbeitrag je Stunde. Ohne Versionsstand dauert die Wiederinbetriebnahme vier Stunden, weil rekonstruiert statt zurückgerollt wird. Mit Versionsstand ist sie nach einer Stunde erledigt, und ein Teil der Vorfälle entsteht gar nicht erst, weil Änderungen vor dem Rollout geprüft werden.
Siemens beziffert Stillstandskosten für große Werke auf 36.000 USD je Stunde in der Konsumgüterindustrie. Unsere 15.000 € sind eine Modellannahme für den Mittelstand, Posten für Posten hergeleitet im Beitrag zu den Kosten von Maschinenstillstand. Mit Ihren eigenen Zahlen rechnet der ROI-Rechner.
| Posten | Ordner-Workflow | Versioniert |
|---|---|---|
| Softwarebedingte Stillstände pro Jahr | 2 | 0,7 |
| Dauer je Vorfall | 4 Stunden | 1 Stunde |
| Stillstandskosten je Stunde | 15.000 € | 15.000 € |
| Kosten pro Jahr | 120.000 € | 10.500 € |
Modellannahmen für eine Linie, keine Messung in einem bestimmten Werk. Die Zahl trägt sich auch, wenn Sie nur einen softwarebedingten Stillstand pro Jahr ansetzen. Dann bleiben 54.750 €. Nicht eingerechnet ist /02, die Wartezeit auf den einen Kollegen, weil sie sich nicht sauber beziffern lässt.
Welcher Weg aus dem Ordner passt zu Ihrer Anlage?
octoplant, Hersteller-Integration oder erst einmal eine Anlage sauber aufsetzen. Welcher Weg trägt, hängt an Ihrem heutigen Archiv und daran, wie viele Steuerungshersteller im Schaltschrank stehen. Zwei Klicks, und Sie springen an die Stelle im Artikel, die Ihren Fall behandelt.
Wo liegen Ihre SPS-Stände heute?
Visuelle Sprachen.
Binäre Formate.
Kein Diff.
Git ist für textbasierte Programmiersprachen konzipiert. Seine Stärke ist das diff, also der zeilenweise Vergleich zweier Versionen. Er setzt voraus, dass Dateien als menschenlesbarer Text vorliegen.
Die SPS-/PLC-Programmierung hat sich historisch anders entwickelt. Die meisten Programme werden in visuellen Sprachen geschrieben, also in Ladder Diagram (LD), Function Block Diagram (FBD) oder Sequential Function Chart (SFC), und in herstellerspezifischen Binärformaten gespeichert. Wie git-tauglich die einzelnen Plattformen sind, vergleicht der SPS-Hersteller-Überblick zu Tools, Git & CI/CD. Dort steht auch, welches SPS-Vergleichstool zwei Programmstände gegenüberstellt: Hersteller-Editor, octoplant oder Git-Diff.
Spezialisierte Lösungen wie octoplant (AMDT, ehemals versiondog) oder Copia Automation übersetzen proprietäre Formate in darstellbare Strukturen, rendern Ladder-Logic-Änderungen visuell und bieten den bekannten Git-Workflow, ohne dass Automatisierungsingenieure zu Softwareentwicklern werden müssen.
Siemens hat mit TIA Portal V21 (SPS 2025 in Nürnberg) die Git-Integration massiv erweitert. Das neue Version Control Interface (VCI) exportiert SPS-Objekte in LAD, FBD und SCL als textbasierte Formate, die mit Standard-Git diff-fähig sind. Ein Quantensprung gegenüber dem eingeschränkten XML-Export früherer Versionen (ab V18).
Beckhoff TwinCAT 3 unterstützt Git nativ, B&R hat ebenfalls Git-Integration eingebaut. CODESYS-basierte Systeme lassen sich über Simatic AX oder textbasierte Exports anbinden.
“Der typische Automatisierungsingenieur hat Git nie gebraucht — und hat deshalb das Risiko nie gesehen. Bis die Maschine steht und niemand weiss, welches Backup funktioniert.
Kein Trend.
Realität.
Der globale IT/OT-Convergence-Markt wächst mit 12,6 % CAGR und soll bis 2030 die 100-Milliarden-Dollar-Marke überschreiten. Allein der Fertigungssektor verantwortet über 35 % aller IT/OT-Implementierungen. Das erklärte Ziel ist meist Predictive Maintenance und höhere Produktionseffizienz.
Gleichzeitig wächst der Druck von einer anderen Seite: Cybersicherheit. Cybersecurity-Integrationen in IT/OT-Plattformen wachsen mit 25 % pro Jahr. 2025 war die Fertigung das dritte Jahr in Folge die am häufigsten angegriffene Branche durch Ransomware. Im Mai 2025 stoppte Nucor, Nordamerikas größter Stahlproduzent, nach einem Cyberangriff die Produktion an mehreren Standorten.
Eine lückenlose Versionsverwaltung ist ein Sicherheitsmerkmal, nicht bloß ein DevOps-Komfort. Wer jederzeit weiss, welcher Code auf welchem Gerät läuft und wer ihn zuletzt geändert hat, kann unautorisierte Eingriffe erkennen, bevor sie zur Katastrophe werden.
Der Markt
spricht Klartext.
| Kennzahl | Wert | Quelle |
|---|---|---|
| Git-Marktanteil (klass. SW-Entwicklung) | 80 % | Copia Automation / Control Engineering |
| VCS-Marktwachstum CAGR 2024-2031 | 9,3 % | Verified Market Research, Nov. 2025 |
| IT/OT-Convergence-Markt 2024 | 50 Mrd. $ | Virtue Market Research, 2025 |
| IT/OT-Convergence-Markt 2030 (Prognose) | 101 Mrd. $ | Virtue Market Research, 2025 |
| Industriesoftware-Markt 2024 | 160 Mrd. $ | IoT Analytics, Dez. 2024 |
| Industriesoftware CAGR bis 2030 | 13,5 % | IoT Analytics, Dez. 2024 |
| Anteil Fertigung an IT/OT-Deployments | 35 % | Virtue Market Research, 2025 |
| Wachstum IT/OT-Partnerschaften 2024 | +18 % | Virtue Market Research, 2025 |
| Wachstum Cybersecurity-Integration OT | +25 % p.a. | Virtue Market Research, 2025 |
Von der Theorie
zur Praxis.
Der VCS-Markt wächst primär deshalb so schnell, weil CI/CD-Pipelines eine robuste Versionsverwaltung voraussetzen. Ohne stabile Grundlage kollabiert jede Automatisierung.
Entwicklung IDE/TIA
Git Commit + Push
Code-Review
Pull Request Freigabe
Deployment PLC/HMI
Monitoring & Rollback
Jenkins ist in der Industrial DevOps-Welt das am weitesten verbreitete Automatisierungswerkzeug und lässt sich in genau diesen Workflow einbinden. Änderungen an PLC-Code triggern automatisch einen Build-Prozess: Syntaxprüfung, Simulation, Testfälle. Erst nach erfolgreicher Pipeline wird der Code zur Deployment-Freigabe vorgelegt. Wie Comquent diesen Ablauf konkret aufsetzt, zeigt der Anwendungsfall CI/CD für SPS & TIA Portal im Maschinenbau.
Relevante Tools & Plattformen
| Kategorie | Tool |
|---|---|
| Versionsverwaltung | Git, GitHub, GitLab, Gitea (on-premise) |
| CI/CD-Automatisierung | Jenkins, GitLab CI |
| PLC-Git-Integration (Siemens) | TIA Portal VCI (V18/V21) |
| PLC-Git-Integration (Beckhoff) | TwinCAT 3 native Git |
| OT-Speziallösung | octoplant (AMDT), Copia Automation |
| Textbasiertes PLC-Framework | Simatic AX (Siemens), CODESYS + Git |
Drei Hürden.
Pragmatisch angehen.
- /01
Kultureller Widerstand
Git-Konzepte erzeugen Skepsis.
Automatisierungsingenieure sind keine Softwareentwickler und wollen es meist auch nicht sein. Git-Konzepte wie Branch, Merge oder Rebase erzeugen Skepsis.
LösungEinführung in Phasen, beginnend mit der simpelsten Funktion, nämlich automatischem Backup mit Rollback-Fähigkeit. Das löst ein unmittelbares Problem, ohne Komplexität aufzuzwingen.
- /02
Proprietäre Formate und Legacy-Systeme
Jeder Hersteller, jedes Binärformat.
Nicht jede SPS lässt sich morgen in einen Git-Workflow integrieren. Siemens, Rockwell, Beckhoff. Jede Umgebung hat ihr eigenes Binärformat.
LösungExport-basierte Ansätze (XML-Export, dann Versionierung) sind akzeptable Zwischenlösungen. Wichtig ist, dass der Prozess definiert ist, auch wenn das Tool noch nicht ideal ist.
- /03
Netzwerktrennung und Air-Gap
OT-Netzwerke ohne Internet.
Viele OT-Netzwerke sind aus gutem Grund vom Internet getrennt. Cloud-basierte Git-Dienste sind hier keine Option.
LösungSelf-hosted Git-Instanzen (Gitea, GitLab on-premise) lösen das Problem vollständig. Das Repository bleibt im eigenen Netz, Compliance-Anforderungen bleiben erfüllt.
Starten Sie nicht mit dem komplexesten System. Starten Sie mit dem drängendsten Problem: Welche Anlage läuft mit unbekanntem Code-Stand? Dort beginnt die Versionsverwaltung, zunächst als strukturiertes Backup. Der Rest kommt schrittweise.
versiondog. octoplant.
Copia. Git nativ.
octoplant ist die Nachfolgeplattform von versiondog, beide vom Hersteller AMDT (vormals AUVESY-MDT). versiondog und AutoSave haben am 31. Dezember 2025 ihr End-of-Life erreicht. Seitdem gibt es dafür weder Support noch Code-Arbeit, und neue Geräte oder Editor-Versionen werden nicht mehr angebunden. octoplant führt beide Produktlinien in einer Oberfläche zusammen, versioniert über 100 Gerätetypen und bringt eine erweiterte Rechteverwaltung mit. Das Prinzip bleibt dasselbe: ein zentrales Archiv mit automatischem Geräteabgleich.
Die wichtigsten Tools für die SPS-Versionsverwaltung sind TIA Portal V21 (VCI), Beckhoff TwinCAT 3, octoplant (AMDT, ehemals versiondog) und Copia Automation, ergänzt um Gitea oder GitLab On-Premise für Air-Gap-Umgebungen. Die Wahl hängt von der Anlagenlandschaft, den Herstellern und den Compliance-Anforderungen ab.
Achten Sie beim Lesen der Tabelle besonders auf den automatischen Geräteabgleich: Das ist die Spalte, an der sich /03 entscheidet, also die Frage, ob auf der Anlage wirklich das läuft, was im Archiv liegt.
| Tool | Typ | Git? | Hersteller | On-Prem? | Besonderheit |
|---|---|---|---|---|---|
| TIA Portal V21 (VCI) | Hersteller-nativ | Ja | Siemens S7-1200/1500 | Ja | LAD/FBD/SCL diff-fähig, neues Exportformat seit SPS 2025 |
| TIA Portal V18 (VCI) | Hersteller-nativ | Ja | Siemens S7-1200/1500 | Ja | XML-Export, eingeschränkte Diff-Fähigkeit |
| Beckhoff TwinCAT 3 | Hersteller-nativ | Ja | Beckhoff | Ja | Nativer Git-Support, textbasiertes ST |
| octoplant (AMDT) | OT-Speziallösung | Eigenes VCS | 100+ Systeme (Siemens, Rockwell, ABB, ...) | Ja | Auto-Backup-Scheduling, visuelle Diffs |
| Copia Automation | OT-Speziallösung | Ja | Siemens, Rockwell, Beckhoff, Schneider | Cloud | Git-native Plattform, Ladder-Logic Rendering |
| Gitea / GitLab On-Premise | Open Source Git | Ja | Alle (manueller Export nötig) | Ja | Kostenlos, Air-Gap-tauglich, Export-Workflow |
- /01
Was ist versiondog?
versiondog ist ein Datenmanagement- und Versionsverwaltungssystem für die Automatisierungstechnik, entwickelt vom deutschen Hersteller AUVESY. Es sichert SPS-, HMI-, Roboter- und Antriebsprojekte herstellerübergreifend und gleicht den laufenden Gerätestand automatisch gegen das Archiv ab, also genau den Abgleich, den ein reines Netzlaufwerk nie liefern konnte. Nach der Fusion von AUVESY mit MDT Software firmiert der Anbieter als AMDT. Installationen laufen vielerorts weiter, das Produkt selbst ist seit Ende 2025 abgekündigt. - /02
Was ist octoplant und wie hängt es mit versiondog zusammen?
octoplant ist die Nachfolgeplattform von versiondog und AutoSave unter dem Dach von AMDT. Sie führt beide Produktlinien in einer Oberfläche zusammen, versioniert über 100 Gerätetypen, plant Backups automatisch und stellt Ladder Logic visuell als Diff dar. Wichtig für die Architekturentscheidung: octoplant ist kein verteiltes Versionskontrollsystem wie Git, sondern ein zentrales Archiv mit Client-Server-Modell. - /03
octoplant vs. versiondog: Was ändert sich bei der Migration?
Die Frist ist abgelaufen: Seit dem 1. Januar 2025 gab es für versiondog nur noch sicherheitskritische Patches, seit dem 31. Dezember 2025 gar keinen Support mehr. Fachlich bleibt das Prinzip gleich, also zentrales Archiv, automatischer Geräteabgleich und Versionsstände je Komponente. Neu sind die einheitliche Oberfläche über alle Gerätetypen, eine erweiterte Rechteverwaltung und Schnittstellen Richtung IT-Tooling. Behandeln Sie den Wechsel als Projekt mit Bestandsaufnahme, Testarchiv und Schulung, nicht als Versions-Update über Nacht. - /04
Welche Alternativen zu versiondog und octoplant gibt es?
Drei Alternativen sind in der Praxis relevant: Copia Automation als Git-native Plattform mit Ladder-Logic-Rendering, die native Hersteller-Integration (TIA Portal V21 mit VCI, Beckhoff TwinCAT 3 mit nativem Git) und Open-Source Git über Gitea oder GitLab On-Premise. Open-Source Git kostet nichts und ist Air-Gap-tauglich, setzt aber herstellerseitige Exportformate voraus. Für gemischte Anlagenlandschaften mit vielen Herstellern bleibt eine OT-Speziallösung meist der pragmatischere Weg.
Das ist /05, und es ist der einzige Schmerzpunkt mit einem Datum. Wer heute noch versiondog betreibt, betreibt eine zentrale OT-Anwendung ohne Patch-Pfad. Das Archiv arbeitet weiter und die Backups laufen, deshalb fällt es im Alltag nicht auf. Auffallen wird es beim nächsten Umbau, wenn eine neue Steuerung oder eine neue Editor-Version dazukommt und das Archiv sie nicht mehr anbindet.
Die Entscheidung steht damit ohnehin an. Es sind zwei Wege. Der eine führt auf octoplant, also auf dasselbe Prinzip mit demselben Hersteller und dem geringsten Bruch im Betriebsablauf. Der andere führt auf Git, entweder über die Hersteller-Integrationen oder über eine eigene Instanz im OT-Netz. Dieser Weg kostet mehr Einarbeitung und öffnet dafür den Anschluss an CI/CD, Pull-Request-Freigaben und Prüfungen vor dem Rollout.
Was in einer gewachsenen Landschaft trägt, hängt an der Zahl der Hersteller im Schaltschrank und daran, wie viel Automatisierung danach folgen soll. Bei drei oder mehr Herstellern und ohne Ambition Richtung Pipeline ist octoplant der ruhigere Weg. Bei Siemens- oder Beckhoff-Schwerpunkt und dem Ziel, Steuerungscode irgendwann automatisiert zu prüfen, zahlt sich der Git-Pfad aus.
Dieser Vergleich bleibt bewusst herstellerneutral. Steht bei Ihnen ausschließlich Siemens im Schaltschrank, ist der konkrete Weg über das Version Control Interface der direktere.
Wie Sie TIA Portal mit Git versionieren, beschreibt der Schwesterartikel Schritt für Schritt, inklusive VCI, Openness-API und Anbindung an GitHub oder GitLab. Für das anschließende Ausrollen auf verteilte Anlagen zeigt der Beitrag zu SPS/PLC-Code per GitOps ausrollen die Betriebsseite. Wer statt Eigenbau eine fertige Plattform prüft, findet die Einordnung samt Pilotzahlen unter Software Defined Automation.
Versionsverwaltung
als Compliance-Pflicht.
SPS-Versionsverwaltung ist eine Compliance-Anforderung und nicht bloß eine Frage der Effizienz. Die IEC 62443 fordert in mehreren Bereichen nachvollziehbares Change Management für OT-Systeme. Hier löst sich /04 ein. Wenn der Prüfer wissen will, wer den Baustein auf der Steuerung zuletzt geändert und wer diese Änderung freigegeben hat, zählt der dokumentierte Nachweis, nicht die Erinnerung der Beteiligten.
- /01
SR 7.6: Audit Logging
Alle Änderungen an Steuerungssystemen müssen nachvollziehbar protokolliert werden. Ohne Versionsverwaltung mit Audit-Trail ist diese Anforderung nicht erfüllbar. - /02
SR 3.4: Software and Information Integrity
Die Integrität von Software auf industriellen Steuerungssystemen muss sichergestellt werden. Git-basierte Versionierung mit kryptografischen Hashes liefert genau das. - /03
Zone/Conduit-Modell: Change Management
Änderungen an Systemen innerhalb einer Sicherheitszone müssen kontrolliert und dokumentiert erfolgen. Pull-Request-Workflows mit Vier-Augen-Prinzip setzen das technisch um.
Ohne SPS-Versionsverwaltung mit lückenloser Änderungsverfolgung ist IEC 62443-Compliance praktisch nicht erreichbar. Unternehmen, die jetzt auf Git-basierte Workflows umstellen, erfüllen gleichzeitig regulatorische Anforderungen und verbessern ihre Cybersecurity-Postur. Comquent verbindet diese Aspekte in der DevSecOps-Beratung für industrielle Umgebungen.
In 5 Schritten
zur Git-Versionierung.
Eine Git-basierte SPS-Versionsverwaltung führen Sie in fünf Schritten ein, von der ersten Bestandsaufnahme über das erste strukturierte SPS-Backup mit Rollback bis zur automatisierten Pipeline. Der Einstieg muss nicht komplex sein, sondern schrittweise.
Der erste spürbare Ertrag kommt meist früh. Ein Rollback, das nach einer misslungenen Änderung in Minuten auf den letzten Gutzustand zurückführt, statt eine Nachtschicht zu kosten, überzeugt ein Team mehr als jede Folie. Was diese verkürzte Wiederinbetriebnahme in Euro wert ist, rechnet der Beitrag Was Maschinenstillstand wirklich kostet an einem mittelständischen Werk durch.
Kritischste Anlage identifizieren
Wo läuft SPS-Code ohne bekannten Versionsstand, wo fehlen Backups? Das ist die Anlage aus /01. Dort starten Sie, nicht beim komplexesten System.
Git-Repository aufsetzen
Installieren Sie eine Self-Hosted Git-Instanz (Gitea oder GitLab On-Premise) im OT-Netzwerk. Für Air-Gap-Umgebungen ist keine Cloud-Anbindung nötig. Ein Repository pro Anlage oder Maschinengruppe.
Initialen Code-Stand committen
Exportieren Sie den aktuellen SPS-Code (bei TIA Portal V21 über VCI, bei älteren Versionen als XML-Export) und committen Sie ihn als Baseline. Bei octoplant oder Copia automatisch über die jeweilige Integration.
Änderungsprozess definieren
Legen Sie Commit-Regeln fest: Wer darf ändern? Was muss in der Commit-Message stehen? Führen Sie ein Vier-Augen-Prinzip via Pull Requests ein. Starten Sie einfach. Ein strukturiertes Backup mit SPS-Rollback ist bereits ein enormer Gewinn.
Automatisierung schrittweise ausbauen
Integrieren Sie Automatisierung schrittweise: automatischer Geräte-Abgleich (Repository vs. laufende SPS), CI-Pipeline mit Syntaxcheck und Simulation (z.B. Jenkins), Quality Gates vor dem Deployment.
KI als
nächste Stufe.
88 % der 180 führenden Industriesoftware-Anbieter haben laut IoT Analytics bereits mindestens eine KI-basierte Funktion eingeführt. Für die Versionsverwaltung bedeutet das konkret:
- /01KI-gestützte Code-Reviews für PLC-Logik
- /02Automatische Erkennung gefährlicher Änderungsmuster
- /03Intelligente Commit-Message-Generierung
- /04Anomalie-Erkennung im Diff-Verlauf
Ohne saubere Versionsverwaltung sind diese KI-Features wertlos, weil sich keine Muster in Daten finden lassen, die nie systematisch erfasst wurden. Git ist die Voraussetzung, nicht das Ziel.
Eine Anlage.
Eine Woche.
Eine ehrliche Zahl.
Der erste Schritt braucht weder Budget noch Werkzeugentscheidung. Nehmen Sie die eine Anlage, bei der Ihnen beim Lesen dieses Artikels jemand eingefallen ist. Lesen Sie den Stand aus, der dort tatsächlich läuft, und vergleichen Sie ihn mit dem, was im Ordner liegt.
In den meisten Werken weichen beide voneinander ab. Diese eine Abweichung trägt das Gespräch mit der Geschäftsführung weiter als jede Folie über Industrie 4.0, und die Werkzeugfrage beantwortet sich danach fast von allein, weil Sie die Größe der Lücke kennen. Sie erklären dann auch nicht mehr, warum Anlage_final_V7_WIRKLICHNEU.zip leider nicht das richtige Backup war.
Comquent GmbH mit Sitz in Puchheim bei München begleitet seit 2006 Industrieunternehmen beim Aufbau moderner DevOps-Workflows, von der ersten Git-Einführung bis zur vollständigen CI/CD-Pipeline mit Jenkins. Aus über 47 Projekten in Automotive, Maschinenbau, Fertigung und Logistik kennen wir die typischen Hürden beim Übergang von manueller Versionierung zu strukturierten DevOps-Prozessen.
Was Kunden
wirklich fragen.
- Q.01
- Warum ist Git in der OT-Welt noch nicht Standard?
- Git ist für textbasierte Programmiersprachen konzipiert. SPS-Programme werden jedoch in visuellen Sprachen (Ladder Diagram, Function Block Diagram) geschrieben und in proprietären Binärformaten gespeichert. Standard-Git kann diese Dateien nicht sinnvoll vergleichen. Spezialisierte Lösungen wie Copia Automation oder octoplant (ehemals versiondog) übersetzen diese Formate in darstellbare Strukturen.
- Q.02
- Was kostet fehlende SPS-Versionsverwaltung?
- Der Kostenblock entsteht nicht an der Maschine, sondern bei der Suche nach dem richtigen Stand: Ohne Versionsverwaltung dauert die Wiederinbetriebnahme nach einem softwarebedingten Stillstand rund vier Stunden statt einer, weil rekonstruiert statt zurückgerollt wird. Bei 15.000 Euro Stillstandskosten je Stunde und zwei Vorfällen im Jahr sind das 120.000 Euro gegenüber 10.500 Euro mit Versionsstand, also rund 109.500 Euro Differenz pro Jahr. Die Beträge sind Modellannahmen für eine mittelständische Linie und keine Messung in einem bestimmten Werk. Laut Control Engineering ist der häufigste Grund für verlängerte Ausfallzeiten nach einem Maschinenfehler ohnehin nicht die Hardware, sondern das nicht auffindbare Backup.
- Q.03
- Wie starte ich mit Git-basierter SPS-Versionsverwaltung?
- In 5 Schritten: (1) Kritischste Anlage identifizieren, (2) Git-Repository aufsetzen (Gitea/GitLab on-premise für Air-Gap), (3) Initialen Code-Stand committen, (4) Änderungsprozess definieren (Commit-Regeln, Review), (5) Automatisierung schrittweise ausbauen. Starten Sie mit strukturiertem Backup und Rollback-Fähigkeit, der Rest kommt schrittweise.
- Q.04
- Welche Tools gibt es für SPS-Versionsverwaltung?
- Es gibt drei Kategorien: (1) Native Hersteller-Integration mit Siemens TIA Portal V21 (Git-Support für LAD, FBD und SCL) oder Beckhoff TwinCAT 3 mit nativem Git. (2) Spezialisierte OT-Lösungen wie octoplant (AMDT, ehemals versiondog) und Copia Automation, die proprietäre Formate herstellerübergreifend versionieren. (3) Open-Source Git über Gitea oder GitLab On-Premise für Air-Gap-Umgebungen.
- Q.05
- Was ist versiondog?
- versiondog ist ein Datenmanagement- und Versionsverwaltungssystem für Automatisierungstechnik, ursprünglich vom deutschen Hersteller AUVESY entwickelt. Es sichert und versioniert SPS-, HMI-, Roboter- und Antriebsprojekte herstellerübergreifend und gleicht den Gerätestand automatisch gegen das Archiv ab. Nach der Fusion von AUVESY mit MDT Software firmiert der Anbieter als AMDT; versiondog wird dort in der Nachfolgeplattform octoplant fortgeführt und hat am 31. Dezember 2025 sein End-of-Life erreicht.
- Q.06
- Was ist octoplant?
- octoplant ist die Nachfolgeplattform von versiondog und AutoSave, herausgegeben von AMDT (vormals AUVESY-MDT). Sie versioniert Automatisierungsprojekte über mehr als 100 Gerätetypen hinweg, bietet automatisches Backup-Scheduling, visuelle Diff-Ansichten für Ladder Logic und rollenbasierte Freigaben. Anders als Git ist octoplant kein verteiltes Versionskontrollsystem, sondern ein zentrales Archiv mit Client-Server-Architektur.
- Q.07
- Was ist der Unterschied zwischen octoplant und versiondog?
- octoplant ist die aktuelle Nachfolgeplattform, versiondog das ältere Produkt desselben Herstellers AMDT (vormals AUVESY-MDT). Fachlich arbeiten beide nach demselben Prinzip: zentrales Archiv, automatischer Geräteabgleich, Versionsstände je Komponente. octoplant führt versiondog und AutoSave in einer gemeinsamen Oberfläche zusammen, deckt über 100 Gerätetypen ab und bringt eine erweiterte Rechteverwaltung sowie Schnittstellen Richtung IT-Tooling mit. versiondog hat am 31. Dezember 2025 sein End-of-Life erreicht und erhält seitdem weder Support noch Code-Arbeit.
- Q.08
- Wird versiondog eingestellt?
- versiondog und AutoSave haben am 31. Dezember 2025 ihr End-of-Life erreicht. Seit dem 1. Januar 2025 gab es nur noch sicherheitskritische Patches, seitdem weder Support noch Code-Arbeit, und neue Geräte oder Editor-Versionen werden nicht mehr angebunden. Bestehende Installationen arbeiten technisch weiter, laufen aber ohne Patch-Pfad. Wer heute noch versiondog betreibt, steht vor zwei Wegen: der Migration auf octoplant beim selben Hersteller oder dem Umstieg auf einen Git-basierten Workflow über die Hersteller-Integrationen oder eine eigene Instanz im OT-Netz.
- Q.09
- Was ändert sich bei der Migration von versiondog auf octoplant?
- Fachlich wenig, organisatorisch einiges. Das Prinzip bleibt gleich: zentrales Archiv, automatischer Geräteabgleich, Versionsstände je Komponente. Neu sind die einheitliche Oberfläche über alle Gerätetypen, eine erweiterte Rechteverwaltung und Schnittstellen Richtung IT-Tooling. Weil versiondog und AutoSave seit dem 31. Dezember 2025 End-of-Life sind, ist der Wechsel keine Option mehr, sondern eine Terminfrage. Planen Sie ihn als Projekt mit Bestandsaufnahme, Testarchiv und Schulung, nicht als reines Versions-Update.
- Q.10
- Welche Alternativen zu versiondog und octoplant gibt es?
- Drei Alternativen sind in der Praxis relevant: Copia Automation als Git-native Plattform mit Ladder-Logic-Rendering, die native Hersteller-Integration (TIA Portal V21 mit VCI, Beckhoff TwinCAT 3 mit nativem Git) und Open-Source Git über Gitea oder GitLab On-Premise. Open-Source Git ist kostenlos und Air-Gap-tauglich, setzt aber herstellerseitige Exportformate voraus. Für heterogene Anlagenlandschaften mit vielen Herstellern bleibt eine OT-Speziallösung meist der pragmatischere Weg.
- Q.11
- Welche SPS-Hersteller unterstützen Git nativ?
- Beckhoff TwinCAT 3 unterstützt Git nativ, da Structured Text bereits textbasiert vorliegt. Siemens TIA Portal bietet ab V18 ein Version Control Interface (VCI) mit XML-Export, ab V21 zusätzlich diff-fähige LAD/FBD/SCL-Formate. B&R hat ebenfalls eine Git-Integration eingebaut. Für Hersteller ohne native Unterstützung übernehmen octoplant oder Copia Automation die Anbindung.
- Q.12
- Kann ich TIA Portal V21 mit Git nutzen?
- Ja. Siemens TIA Portal V21 (vorgestellt auf der SPS 2025 in Nürnberg) hat die Git-Integration massiv erweitert. Das neue Version Control Interface (VCI) exportiert PLC-Objekte in LAD, FBD und SCL als textbasierte Formate, die mit Standard-Git diff-fähig sind. Ältere Versionen (ab V18) bieten ein eingeschränktes VCI mit XML-Export.
- Q.13
- Was kostet octoplant vs. Open-Source Git?
- octoplant (AMDT) ist eine kommerzielle Lösung mit Lizenzkosten, bietet dafür Out-of-the-Box-Integration für über 100 Automatisierungssysteme, automatisches Backup-Scheduling und visuelle Diff-Ansichten. Open-Source Git (Gitea, GitLab) ist kostenlos, erfordert aber mehr Setup und funktioniert nur mit herstellerseitig unterstützten Exportformaten. Für heterogene Anlagenlandschaften mit vielen Herstellern ist octoplant oft die pragmatischere Wahl.
- Q.14
- Welche Norm fordert Versionsverwaltung in der Produktion?
- IEC 62443 (Industrial Automation and Control Systems Security) fordert in mehreren Bereichen nachvollziehbares Change Management für OT-Systeme: SR 7.6 (Audit Logging), SR 3.4 (Software and Information Integrity) und das Zone/Conduit-Modell setzen eine lückenlose Änderungsverfolgung voraus. Ohne Versionsverwaltung ist IEC 62443-Compliance praktisch nicht erreichbar.
- Q.15
- Ist Git oder SVN für SPS-Programme besser?
- Git ist für SPS-Programme klar die bessere Wahl: verteilte Architektur (funktioniert offline und in Air-Gap-Umgebungen), Branching für parallele Entwicklung, und das gesamte OT-Tooling-Ökosystem (Copia, octoplant, TIA Portal VCI) setzt auf Git. SVN bietet keinen nennenswerten Vorteil mehr. Die Branche hat sich entschieden.
- Q.16
- Ist SPS-Versionsverwaltung auch ein Sicherheitsthema?
- Ja. Versionsverwaltung ist ein kritisches Sicherheitsmerkmal für OT-Umgebungen. Wer jederzeit weiß, welcher Code auf welchem Gerät läuft und wer ihn zuletzt geändert hat, kann unautorisierte Eingriffe erkennen (OT Change Detection). Cybersecurity-Integrationen in IT/OT-Plattformen wachsen mit 25 % pro Jahr. Die Fertigung war 2025 das dritte Jahr in Folge die am häufigsten durch Ransomware angegriffene Branche.
Erste Anlage.
Erster Commit.
Erstes Rollback.
Wir begleiten Sie vom ersten Assessment bis zur automatisierten Pipeline, angepasst an Ihre Anlagenlandschaft und Compliance-Anforderungen. Der Einstieg ist bewusst niederschwellig: 30 Minuten Erstgespräch, kostenlos und unverbindlich. Sie entscheiden danach, ob mehr daraus wird.
Wie geht es bei Ihnen mit der SPS-Versionsverwaltung 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
TIA Portal mit Git versionieren: VCI, Openness & CI/CD
Der konkrete How-to: SPS-Code aus TIA Portal über VCI oder Openness an Git anbinden.
CI/CD für SPS-Entwicklung: TIA-Portal mit Jenkins
Schritt-für-Schritt: Build, Test und Deployment von TIA-Portal-Projekten automatisieren.
Was ist Industrial DevOps? Der komplette Leitfaden
DevOps-Prinzipien für cyber-physische Systeme und Industrie 4.0.
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