SCADA mit Git
versionieren.
Per Pipeline
ausrollen.
SCADA-Projekte lassen sich mit Git versionieren, bei Ignition 8.3 und WinCC OA sogar ohne Umweg. Wer Projekte, Tags und Skripte aus dem Repository ausrollt und vorher in einer Sandbox testet, pflegt sechzig Anlagen mit einem Bruchteil der Handarbeit und weiß bei jeder, welcher Stand dort läuft.
Andreas Schönfeld
Geschäftsführer, Comquent GmbH
20 Jahre Industrial DevOps in Maschinenbau, Automotive und Fertigung. Schwerpunkt: CI/CD für SCADA, MES und Edge, OPC-UA-Integration und IT/OT-Konvergenz.
AIWie kommt ein SCADA-Projekt in Git und CI/CD?
Die Antwort in drei Sätzen, danach der Weg für Ihre Plattform.
Das Team exportiert Projekt, Tags, Alarme, Bilder und Skripte in ein Textformat und legt es in einem Git-Repository ab. Jeder Commit läuft durch eine Pipeline, die das Projekt in einer Sandbox startet und prüft. Erst der freigegebene Stand geht auf die SCADA-Server und Edge-Gateways im Werk.
Wie weit das trägt, entscheidet die Plattform. Ignition 8.3 und WinCC OA legen ihre Konfiguration als Dateien ab, die Git direkt versteht. Bei WinCC Unified und AVEVA System Platform bleibt ein Teil binär und braucht einen Export-Schritt. Abschnitt 03 zeigt die Unterschiede im Einzelnen.
In einer Smart Factory greifen MES, Edge-Analytics und Predictive Maintenance auf Daten zu, die SCADA erfasst. Benennt jemand dort einen Tag um, fällt das drei Systeme weiter in einem leeren Dashboard auf. Deshalb zahlt sich Versionierung gerade auf dieser Ebene aus. Wie wir das auf MES und Edge ausweiten, beschreibt der Anwendungsfall DevOps für die Fertigungsindustrie.
Ist SCADA-Versionierung 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.
Woran scheitert manuell gepflegtes SCADA?
Vier Symptome, und jedes kostet am Ende Verfügbarkeit.
Baugleiche Anlagen laufen auseinander
Linie 2 in Werk A und Linie 2 in Werk B waren bei der Abnahme identisch. Fünf Jahre Inbetriebnahme-Korrekturen, Anpassungen in der Nachtschicht und ein Dienstleisterwechsel später sind sie es nicht mehr, und niemand kann sagen, an welcher Stelle sie auseinanderliefen. Am Anfang solcher Projekte legen wir deshalb meist die Projektsicherungen beider Linien nebeneinander und zählen die Unterschiede.
Änderungen ohne Historie
Wer hat den Alarm-Schwellwert geändert, wann und warum? Der Kollege, der es wüsste, ist vor zwei Jahren gegangen, und sein Wissen steckt in keinem Backup. Ohne Versionierung bleibt das Bauchgefühl. Für Einrichtungen, die unter das NIS2-Umsetzungsgesetz fallen, ist das seit Dezember 2025 auch ein Nachweisproblem.
Rollback ohne sauberen Stand
Ein fehlerhaftes Update legt die Visualisierung lahm. Ohne letzten sauberen Stand wird aus dem kurzen Zurückrollen eine nächtliche Rekonstruktion aus Backups unklaren Alters. Im schlechtesten Fall stecken darin Wochen an Faceplate- und Skript-Arbeit, die nie versioniert wurden und nicht mehr zu retten sind.
Updates skalieren nicht
Ein Patch auf 60 SCADA- und Edge-Knoten von Hand bedeutet bei einer halben Stunde pro Knoten eine volle Arbeitswoche. Die bindet genau die Leute, die eigentlich die Produktion am Laufen halten sollen, und jeder Knoten ist eine Gelegenheit für einen Tippfehler.
AIWelche SCADA-Plattform lässt sich wie versionieren?
Ignition und WinCC OA gehen direkt in Git. WinCC Unified braucht einen Export-Schritt, der nicht alles erfasst. AVEVA bringt seit System Platform 2026 den größten Teil als Text mit.
Was landet je Plattform in Git?
Die vier Plattformen im Einzelnen
Ignition 8.3
fast vollständig in Git
Seit Version 8.3 (September 2025) legt Ignition neben den Projekten auch die Gateway-Konfiguration als Dateien im Verzeichnis data/config ab, überwiegend als JSON. Das war der fehlende Baustein. In 8.1 steckte die Gateway-Konfiguration in einer internen Datenbank, und wer Datenbankverbindungen oder Tag-Provider nachvollziehen wollte, musste Gateway-Backups sammeln. Inductive Automation liefert in der Version-Control-Anleitung eine .gitignore-Vorlage mit, Deployment Modes trennen Entwicklung, Staging und Produktion, und eine REST-API schreibt Konfiguration von außen. Vision-Fenster landen als XML in Git, sobald die Projektkodierung von binär auf XML umgestellt ist. Binär bleiben Transaction Groups, Client Tags, Reports und Alarm Pipelines. Die Anleitung schließt sie per .gitignore aus, für sie bleibt das Gateway-Backup zuständig.
WinCC Unified im TIA Portal V21
teilweise in Git
Hier lohnt ein genauer Blick, weil die Ankündigung mehr verspricht, als für SCADA ankommt. Das Version Control Interface exportiert SPS-Bausteine als XML oder im neuen Textformat SIMATIC SD. Von WinCC Unified übernimmt es nur die Global Scripts, als JavaScript plus YAML. Bilder, Faceplates und Alarmkonfiguration stehen nicht in der Liste. Versioniert wird deshalb zweigleisig, die Skripte über das VCI und das Gesamtprojekt als Archiv mit Versionsnummer und Änderungsbeschreibung. Wie das VCI für den SPS-Teil eingerichtet wird, zeigt unser Artikel TIA Portal mit Git versionieren.
WinCC Open Architecture 3.21
Git eingebaut
Unter den Siemens-Produkten ist WinCC OA am besten auf Git vorbereitet. Der Grafikeditor GEDI hat Git-Funktionen eingebaut, ein Eintrag versionControl = "git" im Abschnitt [ui] der Config-Datei schaltet sie frei. Panels lassen sich im offiziellen XML-Format speichern, CTRL-Skripte sind ohnehin Text. Eine fertige Pipeline für Tests und Rollout dokumentiert der Hersteller nicht. Die Voraussetzungen dafür bringt das Produkt aber mit.
AVEVA System Platform
ab 2026 als Text
AVEVA hat am längsten gebraucht und mit der Version 2026 am meisten nachgeholt. Der Galaxy Dump exportiert Objektinstanzen schon länger als CSV. Templates und Grafiken steckten bis 2023 R2 in Exportpaketen der IDE, die Git nur als Binärdatei sieht. System Platform 2026 exportiert Templates als CSV und Grafiken als XML und spielt beides wieder ein, so steht es im Überblick zur Version 2026. Damit liegt der größte Teil einer Galaxy erstmals als Text vor. Eine Git-Anbindung in der IDE gibt es weiterhin nicht. Export, Commit und den Import in eine Sandbox-Galaxy übernimmt deshalb die Pipeline. Wer bisher mit AutoSave for System Platform versioniert hat, braucht ohnehin einen neuen Weg, denn laut einer im AVEVA-Forum zitierten Vertriebsinformation endete dessen Support am 31. Dezember 2025.
AIWie bringen Sie SCADA in fünf Schritten in die Pipeline?
Eine Anlage zuerst, dann die Flotte. Nach rund 30 Tagen läuft der erste automatisierte Rollout.
SCADA-Artefakte als Text exportieren
Erst was sich vergleichen lässt, lässt sich automatisieren.
Projekte, Tag-Listen, Faceplates, Alarmlisten und Skripte kommen in ein Textformat und in ein Git-Repository, statt als Binär-Backup mit Namen wie „final_v3_NEU“ auf dem Netzlaufwerk zu liegen. Ignition 8.3 und WinCC OA liefern Text direkt. Bei WinCC Unified und AVEVA exportiert ein Skript den Teil, der sich exportieren lässt. Was übrig bleibt, legt die Pipeline als Archiv mit Versionsnummer ab, damit auch dieser Teil einen eindeutigen Stand hat.
Sandbox mit Simulation aufbauen
Niemand testet in der laufenden Linie.
Eine isolierte SCADA-Instanz mit OPC-UA-Simulator oder virtueller Steuerung nimmt jede Änderung entgegen, bevor sie in die Nähe der Produktion kommt. Bei Ignition reicht dafür ein Gateway im Docker-Container, in das die Pipeline Konfiguration und Projekte aus dem Repository einbindet. Ein WinCC-Unified-Projekt läuft in der PC Runtime gegen eine Steuerung in PLCSIM Advanced. Ohne diese Umgebung gibt es nichts, wogegen die Pipeline testen könnte. Sie ist deshalb der erste Aufwand, der sich lohnt.
Tests in die Pipeline einziehen
Grün heißt: darf weiter Richtung Werk.
Die Pipeline startet das Projekt in der Sandbox und prüft, ob sich die Tags verbinden. Sie prüft Skripte per Linting und OPC-UA-Server gegen die Companion Specification. Für den letzten Punkt gibt es das Compliance Test Tool der OPC Foundation mit einer Kommandozeile für Build-Systeme, allerdings nur für Mitglieder. Ein Fehler fällt so vor dem Werk auf und nicht erst in der Nachtschicht.
Freigabe über QS in die Produktion
Freigabe ist ein Gate, kein Meeting.
Merge-Request mit Vier-Augen-Prinzip, Audit-Trail und Security-Gates nach IEC 62443 bilden die Promotion von Entwicklung über QS in die Produktion ab. Jede Änderung trägt, wer sie freigegeben hat, wann und gegen welche Tests. Wer unter das seit Dezember 2025 geltende NIS2-Umsetzungsgesetz fällt, hat damit die Nachweise zur Änderungskontrolle, nach denen ein Audit fragt. Will der Auditor wissen, wer einen bestimmten Alarm-Schwellwert freigegeben hat, entscheidet dieses Gate, ob die Antwort fünf Minuten dauert oder fünf Tage.
Rollout automatisieren
Ein Stand für alle Knoten.
Auf Kubernetes-basierten Edge-Knoten zieht ein GitOps-Agent wie Argo CD den freigegebenen Stand selbst. Bei Siemens Industrial Edge übernimmt die Pipeline das Verteilen über die Kommandozeile iectl und die REST-API des Industrial Edge Management. Aus einer halben Stunde Handarbeit pro Knoten wird ein Rollout, der im Wartungsfenster durchläuft. Liegt das Quartals-Update nach acht Minuten auf allen sechzig Knoten und meldet die Übersicht keine einzige Abweichung, geht in die nächste Budgetrunde eine gemessene Zahl statt einer Schätzung.
Wie sieht so ein Repository aus?
Ein Repository je Linie, darin alles, was die Linie zum Laufen braucht. Das Beispiel zeigt eine Linie mit Ignition als SCADA und einer S7-1500 als Steuerung.
Unter tests/ liegt der Smoke-Test aus Schritt 03, unter opcua/ die OPC-UA-Informationsmodelle. Was unter edge/ steht, zieht ein GitOps-Agent auf die Edge-Gateways. Die docker-compose.yml startet die Sandbox aus Schritt 02 auf jedem Entwicklerrechner gleich.
linie-2/ ├── ignition/ │ ├── config/ # Gateway-Konfiguration (data/config, JSON) │ └── projects/ # Perspective-Views, Vision als XML, Skripte ├── plc/ # SPS-Bausteine aus dem TIA Portal (VCI) ├── opcua/ │ └── nodesets/ # Informationsmodelle als NodeSet-XML ├── edge/ # Manifeste für Argo CD oder Industrial Edge ├── tests/ │ ├── smoke/ # Projekt starten, Tag-Verbindungen prüfen │ └── lint/ # Regeln für die Gateway- und View-Skripte ├── docker-compose.yml # Sandbox: Gateway und OPC-UA-Simulator ├── .gitignore # nach der Vorlage von Inductive Automation └── Jenkinsfile
Was spart eine SCADA-Pipeline im Jahr?
Bei 60 Knoten und vier Updates im Jahr rund 110 Stunden. Die Rechnung dazu:
Wir nehmen ein Update pro Quartal auf 60 Knoten an, von Hand rund 30 Minuten pro Knoten einschließlich Prüfung. Dazu kommen zwei ungeplante Stillstände im Jahr, weil ein Knoten einen falschen oder uneinheitlichen Stand hatte.
4 × 60 Knoten × 0,5 h Rollout-Aufwand im Jahr, gebunden an Spezialisten. Die zwei Stillstände durch uneinheitliche Stände und fehlende Rollbacks kommen obendrauf.
Vorbereitung und Freigabe. Der Rollout selbst läuft in Minuten über alle Knoten, Abweichungen meldet der Agent, und ein Rollback ist ein Git-Revert.
Illustrative Beispielrechnung · Werte für Ihre Anlagenzahl im ROI-Rechner
AIOb die Rechnung für Ihre Anlagen aufgeht, klären wir in einem fachlichen 30-Minuten-Erstgespräch. Vorbereiten müssen Sie dafür nichts, und eine Verpflichtung entsteht daraus nicht.
Was Teams zu SCADA und Git fragen.
Antworten zu Ignition, WinCC Unified, WinCC OA, AVEVA, Tests und Konfigurationsdrift. Die Grundbegriffe stehen im Glossar-Eintrag SCADA.
- Q.01Wie funktioniert CI/CD für SCADA-Systeme?
- Das Team exportiert Projekt, Tags, Alarme, Bilder und Skripte in ein Textformat und legt es in Git ab. Jeder Commit startet eine Pipeline, die das Projekt in einer Sandbox mit OPC-UA-Simulator startet und die Skripte prüft. Erst ein per Merge-Request freigegebener Stand geht über die QS-Umgebung auf die SCADA-Server und Edge-Gateways im Werk. Wer in einem halben Jahr wissen will, warum ein Grenzwert anders steht, findet die Antwort in der Commit-Historie statt im Gedächtnis eines Kollegen.
- Q.02Kann man Ignition mit Git versionieren?
- Ja, seit Ignition 8.3 fast vollständig. Die Version legt neben den Projekten auch die Gateway-Konfiguration als überwiegend JSON-basierte Dateien im Verzeichnis data/config ab; in 8.1 steckte sie noch in einer internen Datenbank. Inductive Automation liefert dazu eine .gitignore-Vorlage, Deployment Modes für Entwicklung, Staging und Produktion und eine REST-API für die Gateway-Konfiguration. Vision-Fenster speichert der Designer als XML, sobald die Projektkodierung umgestellt ist. Binär bleiben laut Anleitung Transaction Groups, Client Tags, Reports und Alarm Pipelines.
- Q.03Lassen sich WinCC-Unified-Projekte mit Git versionieren?
- Teilweise. Das Version Control Interface (VCI) im TIA Portal V21 exportiert von WinCC Unified die Global Scripts als JavaScript- und YAML-Dateien, Bilder und Faceplates führt die Siemens-Dokumentation dort nicht auf. In der Praxis versioniert man deshalb zweigleisig: Skripte und SPS-Code über VCI, das Gesamtprojekt als Archiv mit Versionsnummer und Änderungsbeschreibung. Das ist weniger elegant als bei Ignition, bringt aber den Teil unter Versionskontrolle, der das Verhalten der Anlage bestimmt: die Logik.
- Q.04Was ist WinCC Unified Collaboration?
- WinCC Unified Collaboration ist eine Runtime-Funktion, mit der ein Unified-Gerät Bilder eines anderen Unified-Geräts (PC Runtime oder Comfort Panel) anzeigen und bedienen kann; über OPC UA kommen Variablen und Alarme dazu. Mit Versionsverwaltung im Engineering hat die Funktion nichts zu tun. Wer mehrere Unified-Stationen konsistent halten will, braucht dafür weiterhin einen versionierten Projektstand und einen kontrollierten Rollout.
- Q.05Wie versioniert man WinCC OA?
- WinCC Open Architecture hat Git im Grafikeditor GEDI eingebaut; der Eintrag versionControl = "git" im Abschnitt [ui] der Config-Datei schaltet die Funktion frei. Panels lassen sich im offiziellen XML-Format speichern, CTRL-Skripte sind ohnehin Text, damit sind Diffs und Code-Reviews ohne Umweg möglich. Die Pipeline für Tests und Rollout baut das Team selbst, der Hersteller dokumentiert dafür keine fertige Lösung (Stand: Version 3.21).
- Q.06Kann man AVEVA System Platform mit Git versionieren?
- Seit System Platform 2026 zum größten Teil, aber nicht direkt aus der IDE. Die Version exportiert Templates als CSV und Grafiken als XML und importiert sie wieder; die Objektinstanzen liefert der Galaxy Dump schon länger als CSV. Diese Dateien lassen sich in Git vergleichen und prüfen, eine eingebaute Git-Anbindung hat die IDE weiterhin nicht. Wer noch auf 2023 R2 arbeitet, versioniert Templates und Grafiken als binäres Exportpaket mit Prüfsumme.
- Q.07Wie testet man SCADA-Änderungen automatisiert?
- Gegen eine Sandbox-Instanz mit OPC-UA-Simulator oder virtueller Steuerung, nie gegen die laufende Linie. Typische Pipeline-Stages sind ein Smoke-Test (startet das Projekt, verbinden sich die Tags?), Linting der Skripte und die Prüfung der OPC-UA-Server gegen die Companion Specification, etwa mit dem Compliance Test Tool der OPC Foundation, das für Mitglieder eine Kommandozeile für Build-Systeme mitbringt. Erst wenn alle Stages grün sind, darf der Stand Richtung Produktion.
- Q.08Wie verhindert CI/CD die Konfigurationsdrift zwischen Anlagen?
- Der Soll-Zustand liegt in Git, und ein Agent vergleicht ihn regelmäßig mit dem, was auf SCADA-Server und Edge-Gateway tatsächlich läuft. Jede Abweichung wird gemeldet und entweder auf den Git-Stand zurückgesetzt oder per Merge-Request übernommen. Ob der Agent automatisch zurücksetzt, entscheiden Sie pro Anlage; in laufender Produktion ist Melden oft die bessere Wahl, weil hinter einer Handänderung auch eine berechtigte Störungsbehebung stecken kann.
Wie geht es bei Ihnen mit der SCADA-Pipeline 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 und Openness ab V21: wie SPS-Code aus dem TIA Portal in Git kommt, die Schwesterdisziplin zu SCADA.
CI/CD für SPS: TIA Portal & Jenkins
Jenkins-Pipelines für SPS-Code, vom Build bis zum Test gegen die virtuelle Steuerung.
GitOps vs. DevOps
Was GitOps von klassischem DevOps unterscheidet und warum der Pull-Ansatz zu Edge-Knoten im Werk passt.
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