Git für die SPS.
GitOps für die Flotte.
Für Steuerungscode ist Git heute Versionsarchiv und Nachweis, für Container am Edge ein echtes Betriebsmodell. Dieser Artikel zeigt, wo die Grenze zwischen beiden verläuft und warum die virtuelle SPS sie gerade verschiebt.
AIGitOps reicht in der Industrie heute bis an die Steuerung heran, aber nicht in sie hinein. Für SPS-Code ist Git vor allem Versionsarchiv und Audit-Trail. Seit TIA Portal V21 und CODESYS File-Based Storage landet dabei deutlich mehr Logik als lesbarer Text im Repository, zusammenführen lässt sich verlässlich aber nur Structured Text. GitOps im engeren Sinn, also ein Agent, der den Soll-Zustand aus Git zieht und laufend abgleicht, gilt für Container am Industrie-Edge: Argo CD, Flux oder Rancher Fleet verteilen Apps auf ganze Anlagen-Flotten. Dazwischen wächst mit der virtuellen SPS eine dritte Ebene, die Steuerungslogik über denselben Weg ausliefert wie jede andere Edge-App.
Ist GitOps in der Industrie 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.
Wo hört Git auf, wo fängt GitOps an?
Git versioniert, GitOps verteilt. Git hält fest, welcher Stand wann von wem geändert wurde. GitOps geht einen Schritt weiter, denn dort liest ein Agent den Soll-Zustand aus dem Repository und sorgt selbst dafür, dass das Zielsystem ihm entspricht.
In einer Fabrik greift dieses zweite Prinzip nicht überall gleich gut. Deshalb lohnt es sich, die Anlage in drei Ebenen zu zerlegen. Die Tabelle ist die Landkarte für den Rest des Artikels: Wer wissen will, wie SPS-Code ins Repository kommt, liest bei Abschnitt 02 weiter. Wer Edge-Apps auf viele Werke verteilen muss, springt zu Abschnitt 04.
AIWie weit kommt SPS-Code heute mit Git?
Weiter als vor einem Jahr, aber nicht so weit wie Web-Code. Textuelle Logik in Structured Text oder SCL verwaltet Git wie jeden anderen Quelltext. Grafische Bausteine landen inzwischen ebenfalls als lesbarer Text im Repository, zusammenführen lassen sie sich trotzdem nur im Ausnahmefall.
Der Ausgangspunkt ist in den meisten Werken derselbe. Der letzte funktionierende Stand liegt als projekt_final_v3.zip auf einem Netzlaufwerk, und wenn die Anlage steht, weiß niemand sicher, welche Version gerade auf der Steuerung läuft. Diese Lücke schließt Git, ganz gleich, wie gut sich der Code später mergen lässt.
Lange galt eine einfache Regel. Text ist diffbar, Grafik ist XML. Kontaktplan, Funktionsbausteinsprache und Ablaufsprache landeten als serialisiertes XML im Repository, und ein Diff zeigte vor allem verschobene Koordinaten. Zwei Hersteller haben das inzwischen geändert. Siemens exportiert seit TIA Portal V21 KOP, FUP, SCL, Datenbausteine und PLC-Datentypen als SIMATIC Source Documents, einem Textformat, das Git zeilenweise vergleichen kann. CODESYS speichert mit File-Based Storage, seit August 2026 in Version 1.0, das ganze Projekt als Ordnerbaum lesbarer Dateien.
AILesbar heißt aber noch nicht mergebar. Ändern zwei Kollegen dasselbe Netzwerk eines Kontaktplans, erzeugt Git einen Konflikt, den man im Texteditor kaum sinnvoll auflöst. Für die SPS-Logik bleibt Git deshalb in den meisten Werken Versionsarchiv und Audit-Trail, kein Merge-Workflow wie in der Web-Entwicklung. Neben der Git-Anbindung der Hersteller-IDEs gibt es Werkzeuge, die Git unter der Haube nutzen und grafische Vergleiche über mehrere Hersteller liefern, etwa Copia, octoplant von AMDT oder PLC-GIT für die S7-1500. Den Weg für das TIA Portal beschreibt unser Leitfaden TIA Portal mit Git versionieren Schritt für Schritt.
Was ändert die virtuelle SPS?
Sie macht Steuerungslogik zu einer App, die über denselben Weg auf die Anlage kommt wie jede andere Edge-Software. Siemens hat die SIMATIC S7-1500V 2023 vorgestellt. Sie läuft als App auf Industrial Edge, übernimmt bestehende TIA-Projekte und wird über das zentrale Industrial Edge Management aktualisiert.
AIFür dieses Thema ist das der eigentlich neue Punkt. Bei einer Hardware-SPS endet die Versionierung am Download-Knopf, und was danach auf der Steuerung läuft, weiß nur die Steuerung selbst. Bei einer virtuellen SPS sind Projektstand und Runtime-Version Teil einer Auslieferung, die ein Management-System verteilt und protokolliert. Die Frage, welcher Stand auf Linie 3 läuft, beantwortet dann eine Liste und nicht der Kollege mit dem Laptop.
2025 hat Siemens mit der S7-1500V F eine fehlersichere Variante angekündigt. Bosch Rexroth geht mit ctrlX OS einen ähnlichen Weg und installiert Funktionen auf der Steuerung als Apps. Phoenix Contact bietet die PLCnext-Steuerung als Virtual PLCnext Control im Container an.
Wir halten die virtuelle SPS für die spannendste Entwicklung in diesem Feld und zugleich für die, bei der man am genauesten hinsehen sollte. Ob eine Zykluszeit auf einem Industrie-PC hält, hängt an Hardware, Betriebssystem und der Last, die daneben läuft. Eine fehlersichere Variante ersetzt keine Abnahme der konkreten Anlage.
Klären Sie vor dem Pilot außerdem, wie Repository und Edge-Management zusammenkommen. Übernimmt das Management den Stand direkt aus Git, oder stößt eine Pipeline nach dem Merge die Auslieferung an? Davon hängt ab, ob der Git-Verlauf am Ende wirklich zeigt, was auf der Anlage läuft.
Wie rollt man Software auf viele Anlagen aus?
Mit einem GitOps-Agent, der in jedem Werk läuft und sich den Soll-Zustand selbst aus Git holt. Moderne Steuerungen und Industrie-PCs fahren Linux und Container. Auf dieser Ebene beschreiben Manifeste den Zustand jeder Anlage, und Werkzeuge wie Argo CD, Flux oder Rancher Fleet gleichen die Realität laufend daran an.
Kommt ein Update zum ersten Mal per Merge auf zwanzig Linien gleichzeitig an, bleibt der USB-Stick in der Schublade, und die Dienstreise zu den Werken fällt aus. Für OT entscheidend ist das Pull-Prinzip. Die Agents bauen die Verbindung von innen nach außen auf und brauchen keinen offenen Port in der Produktionszone, damit passen sie ins Zonenmodell der IEC 62443. Worin sich Pull vom Push klassischer Pipelines unterscheidet, erklärt CI/CD vs. GitOps.
AIUnter den Agents läuft meist ein schlankes Kubernetes. K3s kommt als einzelnes Binary unter 70 MB und betreibt einen Cluster auf einem einzigen Industrie-PC, KubeEdge trennt die Steuerung in der Cloud von den Knoten am Edge. Beide halten die Anlage am Laufen, wenn die WAN-Leitung ausfällt. Den verpassten Stand holt der Abgleich nach, sobald die Verbindung zurück ist.
Wer setzt GitOps in der Industrie ein?
Die belastbaren öffentlichen Referenzen betreffen Edge- und Container-Anwendungen, nicht die zyklische Logik nach IEC 61131-3. Einen öffentlich dokumentierten Fall, in dem eine Serienfertigung ihre SPS-Logik per GitOps ausrollt, kennen wir bisher nicht. Die vier Beispiele zeigen, wie weit die Edge-Ebene heute ist.
Siemens Werk Amberg · Red Hat OpenShift
Das Werk ist von monolithischer IT auf eine Cloud-native Plattform umgestiegen. Laut Siemens ermöglicht GitOps dort tägliche Patches statt zwei Upgrades im Jahr, ohne die Produktion zu unterbrechen. Auf der Plattform laufen unter anderem Predictive Maintenance und eine KI-gestützte Röntgenprüfung von Lötstellen.
Quelle: redhat.comBosch Rexroth ctrlX · Werk Blaichach
Der Linux-basierte ctrlX CORE steuert in Boschs eigener Fertigung sicherheitsrelevanter Produkte. ctrlX OS installiert Funktionen als versionierte Apps und bringt damit Arbeitsweisen aus der Software-Entwicklung auf die Steuerungsebene.
Quelle: bosch.comSiemens Industrial Edge
Eine Container-basierte Edge-Plattform mit zentralem Industrial Edge Management, das Apps auf große Geräteflotten über viele Werke verteilt. Referenzcode liegt öffentlich auf github.com/industrial-edge.
Quelle: siemens.comRed Hat „Industrial Edge“ Validated Pattern
Eine offene Referenzarchitektur, die Hardware, Betriebssystem, Kubernetes und Anwendungen vollständig deklarativ aus Git beschreibt. Enthalten sind eine Anomalieerkennung auf Sensor-Zeitreihen am Edge und das zentrale Nachtrainieren des Modells.
Quelle: validatedpatterns.ioWelche Praktiken haben sich bewährt?
Sechs Regeln, die in fast jedem Projekt wiederkehren, egal welcher Hersteller in der Halle steht. Die ersten vier betreffen die SPS-Logik, die letzten beiden den Weg auf die Anlage.
Logik und Konfiguration trennen
Steuerungslogik gehört in ein eigenes Repository, am besten als Structured Text. Hardware-Konfiguration und Anlagenparameter liegen deklarativ daneben. Beim TIA Portal ergibt sich diese Trennung von selbst, weil das VCI das Gesamtprojekt nicht synchronisiert.
Ein Objekt, eine Datei
Bausteine und Datentypen liegen je Objekt in einer eigenen Datei. Änderungen kollidieren dann nicht in einer Sammeldatei, und Merge-Konflikte werden seltener. Generierte Artefakte schließt eine .gitignore konsequent aus.
Sprache bewusst wählen
Wo Review und paralleles Arbeiten zählen, ist Structured Text oder SCL die bessere Wahl, denn nur dort sind Merges verlässlich. Grafische Sprachen bleiben dort, wo die Fachlichkeit sie verlangt. Ihre Änderungen lassen sich seit TIA Portal V21 und CODESYS File-Based Storage immerhin im Diff lesen.
CI gegen die Simulation
Die Pipeline kompiliert den SPS-Code aus Git und testet gegen die CODESYS-Simulation oder gegen Siemens PLCSIM Advanced, das sich per API skripten lässt. Regressionstests laufen so ohne physische Hardware. Hardware-in-the-Loop braucht es nur noch für Timing und herstellerspezifisches Verhalten.
Pull statt Push am Edge
In OT-Zonen sind eingehende Verbindungen meist verboten. Pull-basierte Agents wie Fleet, Flux oder Argo CD holen den Soll-Zustand selbst und halten sich damit an die Conduits des Zonenmodells nach IEC 62443.
Freigaben über Pull Requests
Jede Änderung läuft über Branch, Review und Merge. Der Pull Request wird zum dokumentierten Freigabeschritt, signierte Commits und Baseline-Tags liefern den Audit-Trail für Abnahme und Compliance.
Wo stößt GitOps in der Anlage an Grenzen?
Selten im Werkzeug. Die Grenzen liegen in Dateiformaten, in der Physik der Anlage und bei den Menschen, die sie seit Jahren betreuen.
Das Gesamtprojekt bleibt binär
Das TIA-Gesamtprojekt (.apXX) ist binär, im Text nicht vergleichbar und nicht auf ältere Versionen konvertierbar. Git verwaltet es nur als versioniertes Artefakt. Auch mit SIMATIC Source Documents bleibt die Hardwarekonfiguration außerhalb des Textexports.
Lesbar heißt nicht mergebar
Grafische Logik ist inzwischen als Text lesbar. Ändern zwei Kollegen dasselbe Netzwerk, lässt sich der Konflikt trotzdem kaum im Editor auflösen. Bei TwinCAT erzeugt die LineID-Drift sogar Diffs, wenn sich nur ein Kommentar geändert hat.
Kein schneller Rollback in der Produktion
Eine laufende Anlage lässt sich nicht wie ein Cloud-Service zwischen zwei Versionen umschalten. Deployments brauchen Wartungsfenster, und Echtzeitverhalten und Anlagensicherheit setzen harte Grenzen.
Proprietäre Werkzeuge und Lizenzen
Die native Git-Anbindung steckt in kostenpflichtigen Editionen wie der CODESYS Professional Developer Edition, TIA Openness ist an Lizenz und Version gebunden. Wer die Toolchain wechselt, baut das Repository oft neu auf.
Automatisierer und Entwickler
Kontaktplan und Hersteller-IDE treffen auf Git, Branches und Code-Review. Wer Anlagen lange mit Online-Änderungen am laufenden Baustein betreut hat, sieht in einem Pull Request zuerst die Wartezeit bis zur Freigabe. An diesem Kulturwandel scheitern mehr Einführungen als an der Technik.
Die Abnahme bleibt Pflicht
Änderungen an abgenommenen, sicherheitsrelevanten Anlagen lösen eine erneute Validierung aus. GitOps liefert die Nachvollziehbarkeit, die formale Abnahme ersetzt es nicht.
Erfüllt der Git-Verlauf die Nachweispflichten?
Zum großen Teil, die Abnahme ersetzt er aber nicht. Die Git-History mit signierten Commits, Baseline-Tags und dokumentierten Reviews liefert die Nachvollziehbarkeit, die OT- und Safety-Normen verlangen.
Spätestens wenn der Auditor fragt, wer die letzte Änderung an der abgenommenen Anlage freigegeben hat, und die Antwort in einem E-Mail-Postfach von 2023 liegt, wird aus Versionierung eine Nachweisfrage. Git beantwortet, wie Sie den Nachweis führen. Ob eine Änderung erneut validiert werden muss, entscheidet weiterhin die Norm.
OT-Security über Zonen und Conduits mit den Security Levels SL1 bis SL4. Pull-basierte GitOps-Modelle ohne eingehende Verbindung passen direkt ins Zonenmodell, signierte Commits und Images dienen als Integritätsnachweis.
Glossar: IEC 62443Die funktionale Sicherheit verlangt ausdrücklich Versions- und Änderungsmanagement. Die unveränderliche Git-History mit Baseline-Tags und Reviews per Pull Request deckt diese Nachweispflicht ab. Sicherheitsrelevante Änderungen müssen trotzdem erneut validiert werden.
Vergleichbare Anforderungen an Rückverfolgbarkeit und Konfigurationsmanagement. Die Nachweisführung über Git lässt sich sinngemäß übertragen.
Glossar: ISO 26262 (Automotive)GitOps vs. DevOps: Was ist der Unterschied?
DevOps ist die Kultur, GitOps das Betriebsmodell. DevOps beschreibt die Arbeitsweise über den gesamten Lebenszyklus und bringt Entwicklung und Betrieb zusammen. GitOps setzt diese Prinzipien für Deployments um, mit Git als Single Source of Truth und einem Agent wie Argo CD oder Flux, der den Ist-Zustand laufend gegen den in Git beschriebenen Soll-Zustand abgleicht. GitOps ist damit eine Umsetzungsform innerhalb von DevOps, kein Ersatz und keine Konkurrenz.
Für die Industrie heißt das: Wer DevOps einführt, entscheidet zuerst über Zusammenarbeit, Freigaben und Verantwortung. GitOps ist eines der Werkzeuge, mit denen sich diese Entscheidungen auf der Edge-Ebene umsetzen lassen. Die reine Begriffsdefinition mit Abgleich und Drift-Korrektur steht im Glossar unter GitOps.
Was fragen Automatisierer zu Git und GitOps?
Kann man SPS-/PLC-Code mit Git versionieren?
Ja, aber nicht jeder Teil gleich gut. Structured Text und SCL verwaltet Git wie normalen Quelltext, mit zeilenweisem Diff und Merge. Grafische Sprachen wie Kontaktplan oder FUP legen TIA Portal V21 und CODESYS File-Based Storage inzwischen als lesbaren Text ab, sie lassen sich damit vergleichen, aber selten zusammenführen. Das binäre TIA-Gesamtprojekt (.apXX) versioniert Git nur als Artefakt.
Wie versioniert man SPS-Code aus dem TIA Portal in Git?
Über das Version Control Interface (VCI), das auch per Openness-API ansprechbar ist. Es exportiert einzelne Objekte wie FBs, FCs, Datenbausteine und Tag-Tabellen in einen Git-Workspace. Seit V21 nutzt der Export SIMATIC Source Documents, ein Textformat für KOP, FUP, SCL, Datenbausteine und PLC-Datentypen. Das Gesamtprojekt bleibt binär und wird nur als Artefakt versioniert.
Welche SPS-Plattformen unterstützen Git am besten?
CODESYS und Beckhoff TwinCAT 3 haben Git direkt in der Entwicklungsumgebung. CODESYS speichert Projekte seit File-Based Storage 1.0 als Baum lesbarer Textdateien, TwinCAT legt jede POU als eigene XML-Datei ab. Phoenix Contact PLCnext ist Linux-basiert und für Hochsprachen und Container voll git-fähig. Das TIA Portal geht den Weg über den Export des Version Control Interface, seit V21 als lesbarer Text. Verlässliche Merges gibt es auf allen Plattformen nur für Structured Text und SCL.
Braucht man ein Spezialtool wie PLC-GIT, Copia oder octoplant?
Nicht zwingend, die Wahl hängt an Sprache und Herstellermix. Die Git-Anbindung der IDE reicht für textuelle Logik und lässt Ihnen volle Kontrolle über Pipelines und Branching. Spezialtools wie Copia, octoplant von AMDT als Nachfolger von versiondog oder PLC-GIT für die Siemens S7-1500 nutzen Git unter der Haube und zeigen grafische Vergleiche über mehrere Hersteller. Das lohnt sich vor allem bei gemischten Flotten, kostet aber Lizenzen und etwas Kontrolle über die Pipeline.
Lässt sich GitOps direkt auf eine SPS anwenden?
Auf eine klassische Hardware-SPS nicht. GitOps im engeren Sinn, also der laufende Abgleich mit Git durch einen Agent, gilt für Container auf Edge-Geräten und Kubernetes, nicht für die zyklische Echtzeitlogik einer SPS. Für die Logik selbst ist Git Versionsarchiv und Audit-Trail. Näher rückt GitOps über die virtuelle SPS, die als App auf Edge-Hardware läuft und über ein zentrales Management verteilt wird.
Was ist eine virtuelle SPS?
Eine virtuelle SPS ist eine Steuerung, die als Software auf Standard-Hardware läuft statt auf einem eigenen Steuerungsgerät. Siemens bietet sie als SIMATIC S7-1500V an, die als App auf Industrial Edge läuft und bestehende TIA-Projekte übernimmt. 2025 kam mit der S7-1500V F eine fehlersichere Variante dazu. Für die Versionierung zählt, dass Projektstand und Runtime-Version gemeinsam über das Edge-Management ausgeliefert werden.
Wie rollt man Software deklarativ auf viele Anlagen aus?
Mit Fleet-GitOps. Werkzeuge wie Rancher Fleet, Flux v2 mit Azure Arc oder OpenShift GitOps mit Argo CD ziehen den in Git beschriebenen Soll-Zustand auf die Edge-Cluster in den Werken. Schlanke Distributionen wie K3s oder KubeEdge laufen auch bei einem Ausfall der WAN-Leitung weiter. Das Pull-Modell ist in OT-Netzen Pflicht, weil eingehende Verbindungen dort meist verboten sind.
Erfüllt der Git-Audit-Trail Compliance-Anforderungen?
Teilweise. Die unveränderliche Git-History mit signierten Commits, Baseline-Tags und Reviews per Pull Request deckt zentrale Nachweispflichten aus IEC 61508/61511 und IEC 62443 ab, denn sie dokumentiert, wer was wann geändert hat. Die formale erneute Validierung und Abnahme sicherheitsrelevanter Änderungen ersetzt sie nicht.
Was ist der Unterschied zwischen GitOps und DevOps?
DevOps ist die übergeordnete Kultur und Arbeitsweise, die Entwicklung und Betrieb zusammenbringt. GitOps ist ein konkretes Betriebsmodell, das diese Prinzipien für Deployments umsetzt, mit Git als Single Source of Truth und einem Agent wie Argo CD oder Flux, der den Zielzustand laufend abgleicht. GitOps ist eine Umsetzungsform innerhalb von DevOps, kein Ersatz.
Ist DevOps zukunftssicher?
Ja. GitOps ersetzt DevOps nicht, es setzt DevOps um. Die Kultur dahinter, also gemeinsame Verantwortung für Entwicklung und Betrieb, kurze Feedback-Zyklen und Automatisierung statt Handarbeit, bleibt der Rahmen. Was sich ändert, sind die Werkzeuge: Wo früher eine Pipeline aktiv deployt hat, holt sich heute ein Agent den Soll-Zustand aus Git. In der Industrie steht diese Entwicklung eher am Anfang, Steuerungen mit Linux und Containern wie PLCnext, ctrlX oder die virtuelle S7-1500V bringen DevOps-Praktiken gerade erst auf die Steuerungsebene.
Ist PLC gleich SPS?
Ja. PLC steht für Programmable Logic Controller und ist die englische Bezeichnung für die speicherprogrammierbare Steuerung, kurz SPS. Beide meinen denselben Industriecomputer, der Maschinen und Anlagen nach IEC 61131-3 in Echtzeit steuert. Für die Versionierung mit Git macht der Name keinen Unterschied.
Was ist Git, und was unterscheidet es von GitLab?
Git ist ein Versionsverwaltungssystem, GitLab eine Plattform, die Git-Repositories zentral bereitstellt. Git protokolliert jede Änderung mit Autor, Zeitstempel und Kommentar und kann jeden früheren Stand wiederherstellen, und zwar verteilt: Jeder Arbeitsplatz hält die vollständige Historie. GitLab, GitHub oder Azure DevOps ergänzen Merge Requests für Reviews, Rechteverwaltung und CI/CD-Pipelines. In der Automatisierung ersetzt Git den Ordner mit projekt_final_v3.zip durch eine lückenlose Historie.
Wie geht es bei Ihnen mit GitOps in der Industrie 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: GitHub, GitLab & CI/CD
Openness-Export, mergefähige Quelltexte und eine CI/CD-Pipeline für SPS-Code.
CI/CD für SPS: TIA Portal mit Jenkins automatisieren
Build, Test und Deployment von SPS-Code in einer durchgängigen Pipeline.
ArgoCD vs. Flux: GitOps-Tools im Vergleich 2026
Architektur, UI, Multi-Cluster und Progressive Delivery im Vergleich.
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