SCADA in Git.
Ignition, WinCC, AVEVA.
Ausrollen statt klicken.
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 dem Aufwand von einer 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, die in fast jedem Werk auftauchen. Sie kosten Verfügbarkeit, nicht nur Nerven.
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. Mit genau dieser Ausgangslage beginnen die meisten SCADA-Projekte, die wir begleiten.
Ä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 und AVEVA brauchen einen Export-Schritt, der nicht alles erfasst.
Ignition 8.3
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. Ein Rest bleibt: Teile der Vision-Ressourcen sind weiterhin binär. Wer neue Oberflächen baut, hat es mit Perspective deshalb leichter.
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
mit Export-Schritt
AVEVA macht es am schwersten. Der Galaxy Dump exportiert Objektinstanzen als CSV, und die lassen sich vergleichen und prüfen. Templates und Grafiken bleiben in Exportpaketen der IDE, die Git nur als Binärdatei sieht. Eine eingebaute Git-Anbindung dokumentiert AVEVA für System Platform 2023 R2 SP1 nicht. Wir versionieren den CSV-Teil deshalb inhaltlich und die Pakete als Artefakt mit Prüfsumme. Die Pipeline importiert beides in eine Sandbox-Galaxy und prüft, ob sich die Objekte fehlerfrei deployen lassen.
Übersicht: was in Git landet und womit getestet wird
Wie 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, und der Rest wird als Archiv mit Versionsnummer abgelegt.
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. 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, fragt in der nächsten Budgetrunde niemand mehr, wofür die Pipeline gut war.
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
Ob die Rechnung für Ihre Anlagen aufgeht, klären wir in einem kostenlosen 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, Tests und Konfigurationsdrift. Die Grundbegriffe stehen im Glossar-Eintrag SCADA.
- Q.01
- Wie 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.02
- Kann man Ignition mit Git versionieren?
- Ja, und seit Ignition 8.3 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-Empfehlung, Deployment Modes für Entwicklung, Staging und Produktion und eine REST-API für die Gateway-Konfiguration. Teile der Vision-Module bleiben binär, Perspective-Ansichten sind Text.
- Q.03
- Lassen 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.04
- Was 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.05
- Wie 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.06
- Wie 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.07
- Wie 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.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance