Smart Factory
mit SCADA.
Versionieren statt klicken.
Die Smart Factory steht und fällt mit SCADA. Wer Projekte, Tags und Skripte aus Git steuert, gegen eine Sandbox testet und per GitOps ins Werk rollt, skaliert von einer Anlage auf hunderte — ohne Konfigurationsdrift.
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.
Was heißt Smart Factory mit SCADA und CI/CD?
Die Antwort in drei Sätzen — für Menschen und für die Maschinen, die sie zitieren.
Eine Smart Factory mit SCADA und CI/CD verwaltet ihre SCADA-Konfigurationen — Projekte, Tags, Faceplates, Alarme und Skripte — als Code in Git und rollt sie über automatisierte Pipelines aus, statt jede Änderung manuell auf einzelnen Systemen zu klicken.
Jede Änderung wird versioniert, gegen eine Sandbox getestet und kontrolliert über GitOps auf SCADA-Server und Edge-Gateways synchronisiert. So skaliert die Fabrik von einer Anlage auf hunderte Knoten — ohne Konfigurationsdrift und mit einem lückenlosen Audit-Trail.
Das ist dieselbe Disziplin, die wir in unserem Anwendungsfall DevOps für die Fertigungsindustrie auf MES, Edge und Predictive Maintenance ausweiten — SCADA ist der Einstieg.
Manuell gepflegtes SCADA bremst die Smart Factory aus.
Die Symptome sind überall gleich — und sie kosten Verfügbarkeit, nicht nur Nerven.
Konfigurationsdrift zwischen Anlagen
Jedes Werk, jede Linie hat ihren eigenen, manuell gewachsenen SCADA-Stand. Niemand weiß mehr genau, was wo läuft — und warum die Linie in Werk B anders reagiert als in Werk A.
Änderungen ohne Historie
Wer hat den Alarm-Schwellwert geändert, wann und warum? Ohne Versionierung bleibt nur das Bauchgefühl — und im NIS-2-Audit ein Problem, weil sich nichts nachweisen lässt.
Rollbacks sind Glückssache
Ein fehlerhaftes Update legt die Visualisierung lahm. Ohne sauberen letzten Stand wird aus „kurz zurückrollen" eine nächtliche Rekonstruktion aus Backups unklaren Alters.
Updates skalieren nicht
Ein Patch auf 80 Edge-SCADA-Knoten von Hand? Das dauert Tage, ist fehleranfällig und bindet genau die Leute, die eigentlich die Produktion am Laufen halten sollen.
SCADA in 5 Schritten in die Pipeline.
Kein Big Bang — ein Wertstrom, eine Anlage, dann die Flotte. In rund 30 Tagen zum ersten automatisierten Rollout.
SCADA-Artefakte als Code exportieren
Erst was diff-bar ist, lässt sich automatisieren.
Projekte, Tag-Pools, Faceplates, Alarmlisten und Skripte in ein textbasiertes Format exportieren und in Git versionieren — statt Binär-Backups auf Netzlaufwerken mit Namen wie „final_v3_NEU". Ignition liefert JSON von Haus aus, bei WinCC und AVEVA übernimmt eine Export-/Backup-Bridge die Übersetzung.
Sandbox- und Simulationsumgebung aufbauen
Niemand testet in der laufenden Linie.
Eine isolierte SCADA-Instanz plus OPC-UA-Simulator oder Sandbox-PLC bereitstellen, gegen die jede Änderung automatisiert geprüft wird, ohne die Produktion zu berühren. Das ist die Voraussetzung dafür, dass Tests überhaupt in die Pipeline dürfen.
Tests in die Pipeline einziehen
Grün heißt: darf weiter Richtung Werk.
Smoke-Tests gegen die Sandbox (startet das Projekt, verbinden sich die Tags?), Validierung der OPC-UA-Modelle gegen die Companion Specification und Linting der Skripte als automatische Stages. Jeder Fehler fällt vor dem Werk auf — nicht im Werk.
Promotion DEV → QS → PROD etablieren
Freigabe ist ein Gate, kein Meeting.
Freigaben, Audit-Trail und IEC-62443-konforme Security-Gates als kontrollierte Promotion zwischen Umgebungen abbilden. Jede Änderung trägt, wer sie freigegeben hat, wann und gegen welche Tests — nachvollziehbar und rückrollbar, wie es NIS-2-Audits verlangen.
Rollout per GitOps automatisieren
Ein Stand, flottenweit.
Den gewünschten Zustand deklarativ in Git halten und über GitOps (z. B. ArgoCD) auf SCADA-Server und Edge-Gateways synchronisieren — in Wartungsfenstern, mit Self-Healing. Aus „Tage pro Gerät" werden „Minuten, flottenweit".
Welche SCADA-Plattform wie in Git kommt.
Ignition ist Git-nativ, WinCC und AVEVA brauchen eine Export-Bridge — getestet und ausgerollt wird am Ende gleich.
Vom Tagewerk zum Knopfdruck.
Eine konservative Rechnung für eine Flotte von 60 SCADA-/Edge-Knoten.
Annahme: ein quartalsweises Update auf 60 Knoten, manuell rund 30 Minuten pro Knoten inklusive Prüfung, plus zwei ungeplante Stillstände pro Jahr durch fehlerhafte oder inkonsistente Stände.
Rollout-Aufwand pro Jahr, gebunden an Spezialisten — plus zwei vermeidbare Stillstände durch Drift und fehlende Rollbacks.
Vorbereitung und Freigabe; der Rollout selbst läuft flottenweit in Minuten. Drift wird per Self-Healing eliminiert, Rollback ist ein Git-Revert.
Illustrative Beispielrechnung · konkrete Werte je nach Anlagenzahl im ROI-Rechner
Was Teams zu SCADA & CI/CD fragen.
Antworten aus der Praxis zu Versionierung, Tests, OPC UA und Konfigurationsdrift.
- Q.01
- Was bedeutet Smart Factory mit SCADA und CI/CD?
- Eine Smart Factory mit SCADA und CI/CD verwaltet ihre SCADA-Konfigurationen (Projekte, Tags, Faceplates, Skripte) als Code in Git und rollt sie über automatisierte Pipelines aus — statt jede Änderung manuell auf einzelnen Systemen zu klicken. Änderungen werden versioniert, gegen eine Sandbox getestet und kontrolliert über GitOps auf Server und Edge-Gateways synchronisiert. So skaliert die Fabrik von einem auf hunderte SCADA-Knoten ohne Konfigurationsdrift.
- Q.02
- Kann man SCADA wie Ignition oder WinCC in Git versionieren?
- Ja. Ignition exportiert Projekte als JSON/Text und eignet sich besonders gut für Git; WinCC und AVEVA System Platform werden über Backup-/Export-Mechanismen und eine Git-Bridge versioniert. Entscheidend ist, dass die Artefakte in ein textbasiertes, diff-bares Format gebracht werden, damit Pull Requests, Code-Review und automatische Tests greifen.
- Q.03
- Wie testet man SCADA-Änderungen automatisiert?
- SCADA-Änderungen werden gegen eine Sandbox-Instanz mit OPC-UA-Simulator oder einer Sandbox-PLC getestet. Typische Pipeline-Stages sind Smoke-Tests (startet das Projekt, verbinden sich die Tags?), die Validierung der OPC-UA-Modelle gegen die Companion Specification und das Linting der Skripte. Erst wenn alle Stages grün sind, läuft die Promotion Richtung Produktion.
- Q.04
- Was hat OPC UA mit der Smart Factory zu tun?
- OPC UA ist der herstellerübergreifende Standard für die Anlagenkommunikation und das Rückgrat der IT/OT-Konvergenz. Companion Specifications wie OPC UA for Machinery vereinheitlichen die Datenmodelle, Pub/Sub und MQTT ermöglichen die Cloud-Anbindung. In CI/CD-Pipelines werden OPC-UA-Server gegen simulierte Clients getestet und die Modelle gegen die Spezifikation geprüft, bevor sie ins Werk gehen.
- Q.05
- Wie verhindert CI/CD die Konfigurationsdrift zwischen Anlagen?
- Konfigurationsdrift entsteht, wenn Anlagen über die Zeit manuell unterschiedlich konfiguriert werden. GitOps löst das, indem der Soll-Zustand deklarativ in Git liegt und ein Agent (z. B. ArgoCD) jede Abweichung erkennt und automatisch zurücksetzt (Self-Healing). Alle SCADA-Knoten laufen so gegen denselben versionierten Stand — Drift wird sichtbar und eliminiert statt geduldet.
Verwandte Artikel
IT/OT-Kulturwandel meistern
Warum der Kulturwandel die größte DevOps-Herausforderung in der Produktion ist — und wie Sie ihn gestalten.
CI/CD für SPS: TIA Portal & Jenkins
Git-Versionierung und Jenkins-Pipelines für SPS-Code — die Schwesterdisziplin zu SCADA in der Smart Factory.
GitOps vs. DevOps
Was GitOps von klassischem DevOps unterscheidet — und warum es der Rollout-Mechanismus fürs Werk ist.
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