Von Andreas Schönfeld, Geschäftsführer der Comquent GmbH. Er arbeitet seit 2006 mit Jenkins und CI/CD. Seit Jahren beschäftigt ihn die Frage, wie man SPS-Programmierung und moderne Software-Versionierung zusammenbringt, also die Stelle, an der Automatisierungstechnik und DevOps aufeinandertreffen.
Comquent bringt die Versionsverwaltung mit Git im Industrial DevOps aus der Projektarbeit mit: Einführungsprojekte in Teams, die bisher mit Netzlaufwerk und Datumsordner gearbeitet haben, Migrationen gewachsener Projektbestände nach Git und der Aufbau der CI/CD-Pipelines, die anschließend darauf bauen und testen.
AI
AITIA-Portal-Code wird mit Git versioniert, indem man die Bausteine als mergefähigen Quelltext (LAD/FBD/SCL, XML, AWL) exportiert und diesen Export in Git verwaltet — nicht die binäre .ap-Projektdatei. Für diese TIA Portal Git Integration gibt es zwei Wege: das ab V18 integrierte Version Control Interface (VCI) und die skriptbasierte Openness-API. Ab V21 schreibt das VCI die Bausteine im Format SIMATIC Source Documents (SIMATIC SD), womit ein git diff die fachliche Änderung zeigt statt umsortierter XML-Knoten. So entstehen echte Diffs, Branches und Code-Reviews. GitHub und GitLab eignen sich gleichermaßen; GitLab/GitHub Actions bringen CI/CD für Export-Konsistenz und PLCSim-Tests gleich mit. CODESYS bietet mit „CODESYS Git“ eine integrierte Alternative.
Aus der Praxis: Viele Automatisierungsteams legen zuerst das komplette TIA-Projekt als Binärdatei in Git ab. Der Frust kommt beim ersten Merge. Zwei Kollegen ändern denselben Baustein, Git meldet einen Konflikt in einer Datei, die kein Mensch lesen kann, und am Ende entscheidet jemand von Hand, wer gewinnt. Die Änderungen des anderen sind weg.
Wer einmal einen Nachmittag Engineering in einem solchen Konflikt hat versinken sehen, vergisst das nicht. Die eigentliche Frage ist deshalb nicht, ob man versioniert, sondern was man versioniert. Da fängt die Arbeit an.
Ist TIA Portal und Git 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.
Steuerungsprojekte für SPS/PLC wachsen über Jahre, oft ohne Versionskontrolle. Der Grund ist technisch: Das TIA-Portal-Projekt ist ein Binärformat. Legt man die .ap-Datei in Git, kann das System sie zwar speichern, aber nicht diffen oder mergen — zwei parallele Änderungen enden im unauflösbaren Konflikt.
Die Folge sind Versionsstände als Projekt_final_v3_NEU.zip auf Netzlaufwerken, ohne Audit-Trail und ohne nachvollziehbare Änderungshistorie. Für ASPICE, IEC 62443 und jede Funktionssicherheits-Argumentation ist das ein Problem. Genau hier setzt unser Anwendungsfall CI/CD für SPS/PLC im Maschinenbau an, von der versionierbaren Codebasis bis zur durchgängigen Pipeline.
Wie sich das im Ernstfall anfühlt, wissen viele Instandhalter aus eigener Erfahrung. Samstagnacht steht die Anlage, der letzte bekannte Stand wird zurückgespielt, und niemand kann mit Sicherheit sagen, ob auf der Steuerung vorher wirklich das lief, was auf dem Netzlaufwerk liegt.
In diesem Moment ist fehlende Versionierung kein Ordnungsproblem mehr, sondern ein Risiko für Stillstandszeit und Gewährleistung. Was eine solche Nacht kostet, rechnet der Beitrag Was Maschinenstillstand wirklich kostet konservativ durch. Und spätestens wenn der Auditor fragt, wer diese eine Änderung wann freigegeben hat, wird aus dem Ordner-Chaos ein Haftungsthema.
AIGit beantwortet im TIA Portal vier Fragen, die ohne Versionsverwaltung offenbleiben: welcher Stand auf der Anlage läuft, wer ihn wann und warum geändert hat, wie zwei Leute gleichzeitig arbeiten, ohne sich zu überschreiben, und wie man auf einen Stand zurückgeht, von dem man weiß, dass er lief. Alles andere, Werkzeugwahl eingeschlossen, folgt daraus.
Die Sätze unten stammen fast wörtlich aus Erstgesprächen. Daneben steht, was der Zustand im Betrieb kostet und was ihn abstellt. Wenn Sie zwei davon wiedererkennen, ist die Frage nach dem Werkzeug nicht Ihre erste.
Beim Rückspielen entscheidet am Ende ein Bauchgefühl. Läuft die Linie danach wieder, weiß trotzdem niemand, ob der Stand vom Netzlaufwerk dem entspricht, was vorher auf der Steuerung lag.
Ein Repository je Steuerung und ein Stichtag, ab dem der Git-Stand verbindlich gilt. Danach beantwortet ein git log die Frage in zehn Sekunden. Erstes Repo in vier Schritten
Bei einer binären Projektdatei endet das in einem Konflikt, den kein Werkzeug auflösen kann. Einer der beiden Stände wird von Hand verworfen, und mit ihm der halbe Tag, der darin steckt.
Quelltext-Export und ein Baustein je Datei. Dann kollidieren nur noch die Stellen, an denen wirklich zwei Menschen dieselbe Logik angefasst haben. Struktur des Repositorys
Ohne Historie wird aus einer Frage von fünf Minuten eine Woche Rekonstruktion aus Mailverläufen und Erinnerung. Für IEC 62443 und ASPICE ist das keine Formalie, sondern eine Lücke im Nachweis.
Jeder Commit trägt Autor, Zeitstempel und Begründung. Das Review vor der Inbetriebnahme wird damit zur dokumentierten Freigabe statt zur mündlichen. IEC 62443 im Glossar
Der aktuelle Stand liegt auf seinem Rechner, die Begründung für die letzte Änderung in seinem Kopf. Bis er zurück ist, ändert niemand etwas, oder es ändert jemand und hinterher weiß keiner, was.
Workspace und Repository liegen auf dem Server, die Commit-Message trägt die Begründung mit. Der Einstieg kostet einen Nachmittag, nicht ein Projekt. SPS-Versionsverwaltung im Überblick
Vor V21 schrieb das Version Control Interface überwiegend XML. Wer das einmal in einem Review gesehen hat, hält Versionierung für SPS-Code danach für Theorie, obwohl das Urteil dem alten Exportformat gilt und nicht der Methode.
Ab V21 exportiert das VCI LAD, FBD und SCL. Ein git diff zeigt dann die Freigabebedingung, die sich geändert hat, statt einer Umsortierung von XML-Knoten. Was V21 am Export ändert
Bausteine mit Know-how-Schutz, CEM-Bausteine und Failsafe-Objekte mit unbekanntem Passwort lassen sich laut Siemens nicht mit einem externen Versionsverwaltungsprogramm synchronisieren. Wer das erst beim Audit bemerkt, hat eine Lücke in der Historie und keine Erklärung dafür.
Die Grenze vor dem Start kennen und in der README festhalten. Was nicht im Workspace liegt, braucht einen zweiten, dokumentierten Weg, etwa das archivierte Projekt mit Versionsnummer und Ablageort. Siemens: Grundlagen zum VCI
Quelle der Auswahl: Erstgespräche und Einführungsprojekte bei Comquent, geordnet nach Häufigkeit. Die Objektgrenzen in Zeile /06 stammen aus der Siemens-Dokumentation zum Version Control Interface, Stand V21.
Die Frage, die uns in Erstgesprächen am häufigsten gestellt wird, lautet nicht ob, sondern womit. VCI, Openness oder gleich ein Spezialwerkzeug. Fast immer kommt sie von jemandem, der die Entscheidung schon zweimal vertagt hat, weil im Projektgeschäft nie der richtige Moment dafür ist.
Alle drei Wege versionieren denselben textuellen Quelltext und unterscheiden sich im Integrationsgrad und im Aufwand. Welcher passt, hängt an Ihrer TIA-Version, dem Git-Know-how im Team und der CI/CD-Tiefe, die Sie brauchen. Die ersten beiden Punkte klären die zwei Fragen unten in zwanzig Sekunden.
Integriert im TIA Portal, Bedienung per Drag & Drop, ab V21 diff-fähiger LAD/FBD/SCL-Export. Wenig Skriptaufwand — erste Wahl für neue Projekte.
Maximale Flexibilität über eigene Export-/Import-Skripte und Naming-Konventionen. Unabhängig von der VCI-Roadmap, ideal für tiefe CI/CD-Integration und Custom-Toolchains.
Nutzen Git unter der Haube und liefern PLC-spezifische Diffs über mehrere Hersteller hinweg — sinnvoll, wenn Siemens, Rockwell und Beckhoff parallel laufen.
Welcher Git-Weg passt zu Ihrem TIA-Portal-Projekt?
Ob VCI, Openness oder Spezialwerkzeug — der richtige Git-Weg hängt an Ihrer TIA-Version und Ihrem Ziel. Beantworten Sie zwei kurze Fragen, und Sie bekommen den Weg, der bei Ihnen am wenigsten Reibung erzeugt.
Mit welcher TIA-Portal-Version arbeiten Sie?
AIBleibt die Frage, was dieses Version Control Interface im Engineering eigentlich ist und wie viel Arbeit darin steckt. Vier Schritte, und der erste kostet Sie zwei Klicks in der Projektnavigation.
Das TIA Portal Version Control Interface (VCI) ist Siemens’ integrierte Schnittstelle zwischen dem Engineering im TIA Portal und einem quellcode-basierten Versionierungssystem wie Git oder Subversion (SVN) — englischsprachige Quellen führen dieselbe Funktion unter „TIA Portal version control“ oder „source control“. Ab V18 ist das VCI Bestandteil des TIA Portal, für V16 und V17 gibt es den VCI Git Connector als Add-In. Man arbeitet mit einem Workspace direkt im Engineering — ohne eigene Export-Skripte.
Im TIA Portal über die Projektnavigation einen Version-Control-Interface-Workspace erstellen und mit einem lokalen Windows-Verzeichnis verknüpfen. Das VCI ist ab V18 integrierter Bestandteil des Engineering-Frameworks.
Bausteine, Typen und PLC-Datenobjekte per Drag & Drop in den Workspace ziehen. Das VCI legt sie als quellcode-basierte Dateien ab — ab V21 als diff-fähiges LAD/FBD/SCL statt des älteren, rein XML-basierten Exports.
Auf das Workspace-Verzeichnis einen Git-Client (VS Code, Git Bash, IDE) ansetzen und gegen GitLab, GitHub, Gitea oder einen On-Prem-Server committen, branchen und mergen. Bausteinvergleiche sind direkt im TIA Portal möglich.
Änderungen aus dem TIA Portal in den Workspace exportieren, per Git versionieren und dieselbe CI/CD-Logik wie beim Openness-Weg anbinden — Export-Checks, PLCSim-Tests und Compliance-Gates greifen unverändert.
Ab TIA Portal V18 nicht. Das Version Control Interface ist Bestandteil der Installation und wird über die Projektnavigation als Workspace angelegt, in V20 und V21 ebenso. Für V16 und V17 stellt Siemens den VCI Git Connector als Add-In über den Industry Online Support bereit, installiert wird es wie jedes andere TIA-Add-In.
Was das VCI in keiner Version mitbringt, ist der Git-Client selbst. Commit, Branch und Merge laufen über ein separates Werkzeug auf dem Workspace-Verzeichnis, etwa VS Code oder Git Bash.
Wie Sie das Repository darüber hinaus strukturieren und wann OT-Speziallösungen wie octoplant oder versiondog die bessere Wahl sind, vertieft der Beitrag zur SPS-Versionsverwaltung mit octoplant, versiondog und Git. Die Begriffe rund um das TIA Portal als Engineering-Framework klärt der Glossar-Eintrag.
Damit ist der Weg klar. Wie komfortabel er wird, entscheidet allerdings Ihre TIA-Version, und zwar deutlicher, als die meisten erwarten.
Zeile /05 der Liste oben hat fast immer dieselbe Ursache: die Version. Über den ersten Eindruck von Git im TIA Portal entscheidet nicht das Repository, sondern das Format, in dem das Engineering exportiert. Die Matrix sagt Ihnen in einer Zeile, wo Sie stehen.
Ab V18 ist das Version Control Interface Bestandteil der Installation, V16 und V17 brauchen den VCI Git Connector als Add-In, und ab V21 wird der Export lesbar diff-fähig. Openness steht in jeder Version als skriptbasierter Weg daneben.
Eine ehrliche Einordnung: Vor V21 war das diff-fähige Arbeiten mit TIA-Quelltext eher ein Versprechen als ein Werkzeug. Der XML-Export war zwar textbasiert, für einen lesbaren Review taugte er kaum. Erst der Export von LAD, FBD und SCL in V21 macht aus „technisch versionierbar“ einen Review-Workflow, in dem sich ein Pull Request auch fachlich diskutieren lässt.
Wer heute anfängt, sollte diese Grenze kennen, statt ältere Versionen schönzureden. Dafür lohnt sich der Weg: In unseren Projekten kippt die Stimmung im Team meist dann, wenn ein Review den ersten Baustein-Fehler vor der Inbetriebnahme fängt statt danach.
In TIA Portal V21 exportiert das Version Control Interface Bausteine als textbasiertes LAD, FBD und SCL — der entscheidende Unterschied zum überwiegend XML-basierten Export ab V18. Ein git diff zeigt damit die fachliche Änderung statt einer Umsortierung von XML-Knoten, und ein Pull Request wird zum Ort, an dem zwei Automatisierer über Logik reden statt über Dateiformate. Am Git-Workflow selbst ändert V21 nichts: Workspace anlegen, Objekte übernehmen, mit einem externen Client committen — die vier Schritte oben gelten unverändert.
Der Unterschied ist im Review sofort sichtbar. Links eine Änderung an einer Freigabebedingung, wie sie im textbasierten Export ankommt — lesbar, kommentierbar, in der Historie auffindbar:
$ git diff HEAD~1 -- PLC_1/ProgramBlocks/FB_Freigabe.scl @@ -42,7 +42,10 @@ IF #Startanforderung AND NOT #Stoerung THEN - #Freigabe := TRUE; + // Freigabe erst nach Quittierung — Nacharbeit KW32, Linie 3 + IF #Quittierung_Bediener THEN + #Freigabe := TRUE; + END_IF; END_IF;
Vor V21 stand an derselben Stelle ein XML-Block mit Attribut-IDs, in dem dieselbe Änderung zwar technisch enthalten, aber praktisch nicht lesbar war. Wer heute auf V21 steht, sollte deshalb genau diesen Unterschied nutzen: Reviews auf Baustein-Ebene einführen, statt Commits nur als Backup zu fahren. Und wer noch auf V18 bis V20 arbeitet, verliert nichts — Repository-Struktur, .gitignore und CI/CD bleiben beim Upgrade identisch, nur die Diffs werden lesbar.
In TIA Portal V20 ist das Version Control Interface fest integriert. Workspace, Drag-&-Drop-Export und die Git-Anbindung über einen externen Client funktionieren wie ab V18, mit breiterer Steuerungsunterstützung. Der Export ist in V20 allerdings noch überwiegend XML-basiert. Bausteinvergleiche gelingen im TIA Portal selbst, ein Standard-Git-Diff bleibt sperrig. Wer den textbasierten LAD/FBD/SCL-Export will, braucht das Upgrade auf V21. Am Git-Workflow ändert der Wechsel nichts.
SIMATIC Source Documents, kurz SIMATIC SD, ist das textbasierte Quelltextformat, in dem TIA Portal Bausteine für S7-1200, S7-1500 und S7-1200 G2 exportiert und wieder importiert. Siemens selbst beschreibt es als Brücke zu moderner Versionsverwaltung. Eingeführt wurde das Format mit V20, damals über Openness und den Projekt-Export erreichbar. Der Sprung für Git kam mit V21, weil dort das Version Control Interface direkt in SIMATIC SD schreibt. Deshalb zeigt ein git diff auf einem V21-Workspace die fachliche Änderung und nicht mehr eine Umsortierung von XML-Knoten.
Falls Sie noch auf V18 bis V20 stehen: Verzeichnisstruktur, .gitignore und Commit-Disziplin sind dieselben, beim Upgrade ändert sich am Repository nichts. Wer dagegen auf V21 wartet, bevor überhaupt ein Repository existiert, verschenkt die Zeit, in der die Historie hätte wachsen können.
Damit ist die Frage nach der Version beantwortet. Offen bleibt die, die im Erstgespräch danach kommt: Wie sieht das erste Repository konkret aus, und in welcher Reihenfolge legt man es an? Genau daran entscheidet sich, ob Sie die binäre Projektdatei später wieder aus der Historie holen müssen.
In vier Schritten: ein leeres Verzeichnis außerhalb des TIA-Projektordners anlegen, dort git init ausführen und die .gitignore schreiben, dann den VCI-Workspace daraufsetzen und die Bausteine übernehmen, zuletzt den ersten Commit setzen. Auf die Reihenfolge kommt es an. Wer zuerst exportiert und danach über die .gitignore nachdenkt, hat die binäre .ap-Projektdatei bereits in der Historie, und die bekommt man nur mit Aufwand wieder heraus.
Hier lösen sich die Zeilen /01, /02 und /04 der Liste oben auf: der unklare Stand auf der Anlage, die zwei Kollegen am selben Baustein und der Kollege, der gerade nicht erreichbar ist. Ein zusätzliches Werkzeug brauchen Sie ab V18 für keinen dieser Schritte. Das Version Control Interface ist Bestandteil der Installation, den Rest erledigt ein gewöhnlicher Git-Client.
Ein eigenes, leeres Verzeichnis außerhalb des TIA-Projektordners anlegen. Das Repository verwaltet später nur den Quelltext-Export; die binäre .ap-Projektdatei bleibt, wo sie ist.
Im leeren Verzeichnis git init ausführen und die .gitignore schreiben, bevor der erste Baustein exportiert wird. Projektdateien, Logs und Cache-Ordner gehören nie in die Historie.
Im TIA Portal einen Version-Control-Interface-Workspace auf dieses Verzeichnis legen und Bausteine, Typen und PLC-Datenobjekte per Drag & Drop übernehmen. Ab V21 schreibt das VCI sie im Format SIMATIC Source Documents (SIMATIC SD).
Ein Baustein je Datei, ein Commit je fachlicher Änderung, aussagekräftige Commit-Message. Dazu schriftlich festhalten, ab welchem Datum der Git-Stand verbindlich gilt und das Netzlaufwerk tabu ist.
Alles, was das Engineering erzeugt und nicht der Quelltext ist: die Projektdatei selbst, Archive, Log- und Temp-Verzeichnisse, lokale Editor-Dateien. Der folgende Startpunkt deckt ab, was uns in Projekten am häufigsten in einer Historie begegnet ist, in die es nie gehört hätte.
# Projekt- und Archivdateien: nie im Repository, nur der Quelltext-Export
*.ap*
*.zap*
*.s7p
# Vom Engineering erzeugte Arbeitsverzeichnisse
Logs/
TMP/
System/
UserFiles/
AdditionalFiles/
# Lokale Reste
*.bak
*.tmp
~$*
.vscode/Ein Verzeichnis je Steuerung, darunter die Bausteine als einzelne Dateien. Das klingt banal, entscheidet aber darüber, ob zwei Kollegen gleichzeitig arbeiten können: Liegen zehn Bausteine in einer Datei, kollidieren sie bei jeder zweiten Änderung. Ein Baustein je Datei, und der Konflikt tritt nur noch dort auf, wo wirklich zwei Menschen dieselbe Logik angefasst haben.
tia-linie-3/
├── .gitignore
├── README.md Stichtag, Zuständigkeiten, TIA-Version
└── PLC_1/
├── ProgramBlocks/
│ ├── FB_Freigabe.scl
│ ├── FB_Transport.scl
│ └── FC_Diagnose.scl
├── PlcDataTypes/
│ └── UDT_Auftrag.scl
└── PlcTags/
└── Variablentabelle.xmlMehr als diese Handvoll Befehle braucht der Einstieg nicht. Alles, was danach kommt, ist Gewohnheit.
$ mkdir tia-linie-3 && cd tia-linie-3 $ git init $ # .gitignore anlegen, BEVOR der erste Export läuft $ git add .gitignore && git commit -m "Repo-Struktur und .gitignore" # Im TIA Portal V21: VCI-Workspace auf dieses Verzeichnis legen, # Bausteine per Drag & Drop übernehmen (Export als SIMATIC SD) $ git status new file: PLC_1/ProgramBlocks/FB_Freigabe.scl new file: PLC_1/ProgramBlocks/FB_Transport.scl $ git add PLC_1 $ git commit -m "FB_Freigabe: Quittierung vor Freigabe (Nacharbeit KW32)" $ git remote add origin git@gitlab.intern:ot/tia-linie-3.git $ git push -u origin main
Wo das VCI an seine Grenze kommt — ältere TIA-Versionen, eigene Namenskonventionen, tiefe CI/CD-Automatisierung —, übernimmt der skriptbasierte Weg über die TIA-Openness-API. Er kostet mehr Aufwand und gibt dafür die volle Kontrolle über Export, Struktur und Pipeline.
Im TIA Portal die TIA Openness-Schnittstelle installieren und den Benutzer zur Gruppe „Siemens TIA Openness“ hinzufügen. Ab TIA Portal V17 ist Openness Bestandteil der Installation.
Bausteine (FB, FC, DB) und PLC-Tags per Openness-Skript als XML bzw. SCL/AWL exportieren. Nur der textuelle Export ist mergefähig — die binäre .ap-Datei gehört nicht ins Git.
Pro Steuerung ein Verzeichnis, Bausteine als einzelne Quelltext-Dateien. Eine .gitignore schließt Binär-Artefakte, Cache und Kompilate aus. Aussagekräftige Commit-Messages je Funktionsänderung.
Re-Import per Openness-Skript automatisieren und gegen das Original diffen, damit der Export/Import verlustfrei bleibt. So wird der Git-Stand zur verbindlichen Quelle.
In Jenkins oder GitLab CI bei jedem Commit Export-Konsistenz prüfen, PLCSim-Smoke-Tests fahren und Engineering-Backups als signierte Artefakte ablegen — IEC-62443-konform.
Was in der Dokumentation glatt aussieht, hat in echten Projekten zwei Stolpersteine. Erstens ist die Openness-API an die TIA-Version gebunden. Wer über einen Versionssprung hinweg exportiert, sollte die Skripte nach jedem Update erneut prüfen, statt sich auf „einmal gebaut, läuft für immer“ zu verlassen. Zweitens gehört der Round-Trip-Test nicht nur einmal zur Absicherung dazu, sondern als fester Schritt in die Pipeline: exportieren, re-importieren, gegen das Original prüfen.
Womit die Pipeline selbst an der Reihe wäre. Sie ist die Stelle, an der sich VCI und Openness wieder treffen, und die Stelle, an der die meisten Projekte zu viel auf einmal wollen.
Ob Sie über das Version Control Interface oder über Openness exportiert haben, spielt ab hier keine Rolle mehr. Im Repository liegt in beiden Fällen Text, und darauf arbeitet jede Pipeline gleich.
GitHub braucht keine Sonderbehandlung: Das VCI- oder Openness-Exportverzeichnis wird als lokales Git-Repository initialisiert und gegen ein Repository auf github.com oder GitHub Enterprise gepusht — Branches, Pull Requests und Code-Reviews funktionieren damit wie in der Software-Entwicklung. GitHub Actions übernimmt die CI/CD-Seite: Export-Konsistenz prüfen, PLCSim-Smoke-Tests fahren, Engineering-Backups als Artefakte signieren. Self-hosted Runner auf einem Windows-Engineering-Host sind dabei Pflicht, weil TIA Portal und PLCSim Windows voraussetzen.
Der unbequeme Teil steht selten im Tutorial: Automatisierte Tests gegen PLCSim in einer Pipeline aufzusetzen ist machbar, aber kein Nachmittagsprojekt. Lizenzierung, die Startzeiten der Simulation und die Frage, was ein Test überhaupt sinnvoll prüft, kosten mehr Zeit als der Git-Teil.
Unsere Empfehlung: klein anfangen. Erst Export und Versionierung sauber automatisieren, dann Build- und Konsistenzprüfungen, und ganz zuletzt die Simulation. Wer alles auf einmal will, baut sich eine Pipeline, die am Ende niemand mehr wartet.
Die PLC-Git-Frage stellt sich nicht nur im TIA Portal — CODESYS und TwinCAT gehen eigene, teils komfortablere Wege. Der Vergleich zeigt, wie nah die jeweilige Plattform an einem nativen Git-Workflow ist.
Bei heterogenen Anlagen mit mehreren Steuerungsherstellern oder wenig Git-Erfahrung im Team können spezialisierte Werkzeuge sinnvoll sein. Sie nutzen Git meist im Hintergrund und ergänzen es um PLC-spezifische, grafische Diffs.
Herstellerübergreifende Versionsverwaltung für Automatisierungsprojekte; interpretiert proprietäre Formate, stellt Ladder-/Grafik-Diffs dar und nutzt Git-Mechanismen (Branches, Rollback) im Hintergrund.
Speziell auf PLC-Versionierung via Git ausgelegt; übersetzt proprietäre Formate in lesbare Strukturen und ergänzt grafische Diffs und Reviews für SPS-Code.
Comquent berät herstellerneutral: Wer volle Kontrolle und CI/CD-Tiefe will, fährt mit nativem Git über VCI oder Openness flexibler — Spezialwerkzeuge spielen ihre Stärke bei gemischten Flotten aus. Wie sich PLC-Code mit Git versionieren und auf ganze Anlagen-Flotten ausrollen lässt, vertieft unser GitOps-in-der-Industrie-Leitfaden. Welches SPS-Vergleichstool zu welchem Hersteller passt — und wie Sie zwei SPS-Programme vergleichen, ordnet der Hersteller-Überblick ein.
Ja. TIA Portal speichert das Projekt zwar binär (.ap-Datei), über die TIA-Openness-API lassen sich Bausteine und Tags aber als mergefähiger Quelltext (XML, SCL, AWL) exportieren. Dieser Export wird in Git versioniert — nicht die Binärdatei. So entstehen nachvollziehbare Diffs, Branches und Code-Reviews wie in der klassischen Softwareentwicklung.
Die .ap-Projektdatei ist ein Binärformat. Git kann Binärdateien zwar speichern, aber nicht sinnvoll diffen oder mergen — zwei parallele Änderungen führen zum Konflikt ohne Auflösungsmöglichkeit. Erst der textuelle Export (über VCI oder Openness) macht Änderungen Zeile für Zeile sichtbar und mehrere Bearbeiter konfliktfrei möglich.
„PLC Git“ bezeichnet die Versionsverwaltung von SPS-/PLC-Code mit Git — also das Versionieren von Steuerungsprogrammen (TIA Portal, CODESYS, TwinCAT) in einem Git-Repository statt auf Netzlaufwerken. Weil SPS-Projekte meist binär gespeichert werden, versioniert man den textuellen Quelltext-Export (LAD/FBD/SCL, XML, AWL), nicht die Projektdatei. So entstehen Diffs, Branches, Code-Reviews und CI/CD-Pipelines wie in der klassischen Softwareentwicklung. Im TIA Portal liefern VCI oder Openness diesen Export, CODESYS und TwinCAT bringen Git-nähere Wege mit.
Ja. Siemens nennt die integrierte Lösung „Version Control Interface“ (VCI) — in englischsprachigen Quellen läuft das Thema unter „TIA Portal version control“ oder „TIA Portal source control“, gemeint ist dieselbe Schnittstelle. Ab V18 verbindet das VCI das Engineering mit quellcode-basierten Systemen wie Git oder Subversion; wer nach „Siemens Git“ sucht, landet in der Regel genau hier. Für ältere Versionen oder tiefe Automatisierung bleibt die Openness-API der skriptbasierte Weg.
Das Version Control Interface (VCI) ist Siemens’ integrierte Brücke zwischen TIA-Portal-Engineering und quellcode-basierten Versionierungssystemen wie Git oder Subversion. Man legt im TIA Portal einen Workspace an, der auf ein Verzeichnis zeigt, übernimmt Bausteine per Drag & Drop und versioniert dieses Verzeichnis mit einem Git-Client. Ab V21 exportiert das VCI diff-fähiges LAD/FBD/SCL statt des älteren XML-Formats.
Ja. Siemens bietet mit dem Version Control Interface (VCI) ab TIA Portal V18 eine integrierte Git-Anbindung; für ältere Versionen existiert der VCI Git Connector als Add-In (ab V16). Ergänzend erlaubt die Openness-API eigene Export-/Import-Skripte für maximale Flexibilität und tiefe CI/CD-Integration. Openness ist also der skriptbasierte, VCI der direkt im TIA Portal integrierte Weg. Comquent richtet beide Toolchains projektspezifisch ein.
Ja, allerdings nicht als Siemens-Produkt. Der VCI Git Connector ist ein TIA-Add-In, das die Dateien eines VCI-Workspace mit Git verwaltet; im Umfeld der TIA-Add-Ins kursieren weitere Git-Connectoren, unter anderem als offener Quellcode auf GitHub. Für V16 und V17 ist ein solches Add-In der einzige integrierte Weg. Ab V18 raten wir eher davon ab: Das Version Control Interface schreibt die Dateien ohnehin in ein gewöhnliches Verzeichnis, und ein etablierter Git-Client wie VS Code oder Git Bash ist besser gepflegt, beherrscht Branches, Rebase und Pull Requests und passt zu dem, was Ihre IT im Haus bereits einsetzt.
Ab TIA Portal V18 braucht es keinen Download: Das Version Control Interface ist Bestandteil der Installation und wird über die Projektnavigation als Workspace angelegt — in V20 und V21 ebenso. Für V16 und V17 stellt Siemens den VCI Git Connector als Add-In über den Industry Online Support bereit. Den Git-Client selbst bringt das VCI in keiner Version mit: Commit, Branch und Merge laufen über ein separates Werkzeug auf dem Workspace-Verzeichnis, etwa VS Code oder Git Bash.
Nicht vollständig. In den VCI-Workspace übernehmen lassen sich Organisationsbausteine, Funktionsbausteine, Funktionen, Datenbausteine, PLC-Datentypen, PLC-Variablentabellen, Technologieobjekte, globale Skripte für HMI Unified und ab V21 auch Bibliothekstypen; Failsafe-Objekte nur, wenn kein Passwort gesetzt ist oder Sie es kennen. Nicht synchronisieren lassen sich laut Siemens-Dokumentation CEM-Bausteine, Bausteine mit Know-how-Schutz und Failsafe-Objekte mit unbekanntem Passwort. Die Hardware-Konfiguration steht ebenfalls nicht in dieser Liste. Halten Sie deshalb in der README fest, welche Teile des Projekts außerhalb des Repositorys gesichert werden, etwa als archiviertes Projekt mit Versionsnummer. Sonst fällt die Lücke erst auf, wenn jemand nach dem vollständigen Stand fragt.
Ja. Das VCI ist auf quellcode-basierte Versionierungssysteme ausgelegt und schreibt lediglich Dateien in ein Workspace-Verzeichnis — ob darauf Git oder Subversion arbeitet, ist dem TIA Portal gleichgültig. Für neue Projekte empfehlen wir dennoch Git: Branches, Pull Requests und die CI/CD-Anbindung an GitLab oder GitHub Actions sind damit deutlich unaufwendiger als mit SVN.
Ja. Das Version Control Interface ist ab V18 Bestandteil der Installation und in V19 ebenso vorhanden, angelegt wird es wie dort über die Projektnavigation. Der Export ist in V19 allerdings noch überwiegend XML-basiert. Sie können damit sauber versionieren, ein Standard-Git-Diff bleibt aber sperrig. Textbasiertes LAD, FBD und SCL schreibt das VCI erst ab V21. Für den Einstieg spielt das keine Rolle. Verzeichnisstruktur, .gitignore und Commit-Disziplin sind in V19 dieselben wie in V21, und beim Upgrade auf V21 ändert sich am Repository nichts.
Für neue Projekte ab V18 (ideal V21) ist das integrierte VCI der komfortablere Weg: weniger Skriptaufwand, Bedienung direkt im TIA Portal. Die Openness-API lohnt sich bei älteren Versionen, eigenen Naming-Konventionen oder besonders tiefer CI/CD-Automatisierung. Beide Wege versionieren denselben textuellen Quelltext in Git und lassen sich kombinieren — die Wahl hängt von TIA-Version und gewünschtem Automatisierungsgrad ab.
TIA Portal V21 baut vor allem das Version Control Interface (VCI) deutlich aus: Bausteine werden als textbasiertes LAD, FBD und SCL exportiert, das sich mit Standard-Git diffen lässt — ein klarer Fortschritt gegenüber dem überwiegend XML-basierten Export ab V18. Parallel verbessert V21 die Openness-API. Bestehende Openness-Skripte sollten beim Versionswechsel gegen die neue API validiert werden.
SIMATIC Source Documents, kurz SIMATIC SD, ist das textbasierte Quelltextformat, in dem TIA Portal Bausteine für S7-1200, S7-1500 und S7-1200 G2 exportiert und wieder importiert. Siemens selbst bezeichnet es als Brücke zu moderner Versionsverwaltung. Eingeführt wurde das Format mit V20, damals über die Openness-API und den Projekt-Export erreichbar. Der eigentliche Sprung für Git kam mit V21, weil dort das Version Control Interface direkt in SIMATIC SD schreibt. Genau das macht ein „git diff“ auf einem VCI-Workspace lesbar: Sichtbar wird die fachliche Änderung, nicht eine Umsortierung von XML-Knoten.
Die TIA Portal Git Integration läuft über zwei Wege: das ab V18 integrierte Version Control Interface (VCI) — Workspace anlegen, Bausteine per Drag & Drop übernehmen, das Verzeichnis mit einem Git-Client versionieren — oder die skriptbasierte Openness-API für ältere Versionen und tiefe CI/CD-Automatisierung. Beide versionieren denselben textuellen Quelltext in GitHub oder GitLab; ab V21 exportiert das VCI direkt diff-fähiges LAD/FBD/SCL. Die binäre .ap-Projektdatei bleibt dabei außen vor.
In vier Schritten: ein leeres Verzeichnis außerhalb des TIA-Projektordners anlegen, dort „git init“ ausführen und die .gitignore schreiben, anschließend im TIA Portal den VCI-Workspace auf dieses Verzeichnis setzen und die Bausteine per Drag & Drop übernehmen, zuletzt den ersten Commit setzen. Die Reihenfolge entscheidet: Wer zuerst exportiert und danach über die .gitignore nachdenkt, trägt die binäre .ap-Projektdatei bereits in die Historie ein und bekommt sie nur mit Aufwand wieder heraus. Ein Baustein je Datei halten, sonst kollidieren zwei Bearbeiter bei jeder zweiten Änderung. Ab V18 genügt dafür das integrierte Version Control Interface, ein zusätzliches Werkzeug braucht es nicht.
Für den Alltag reichen fünf Befehle: clone, pull, commit, push und branch. Wer täglich mit TIA Portal oder CODESYS arbeitet, kommt damit erfahrungsgemäß innerhalb weniger Tage zurecht. Schwierig ist selten das Werkzeug, sondern die Umstellung der Arbeitsweise — kleine, nachvollziehbare Commits statt eines Wochenstands auf dem Netzlaufwerk und ein Review, bevor der Baustein auf die Anlage geht. Genau diese Umstellung entscheidet über den Erfolg der Einführung, nicht der Befehlssatz.
Ja, aus einem anderen Grund als im Team. Der Nutzen liegt dann nicht im parallelen Arbeiten, sondern in der Historie: Sie gehen auf einen Stand zurück, von dem Sie wissen, dass er lief, und Sie lesen zwei Jahre später nach, warum eine Freigabebedingung so aussieht, wie sie aussieht. Dazu kommt der Fall, über den niemand gern spricht. Ist diese eine Person im Urlaub oder nicht mehr im Unternehmen, liegt der aktuelle Stand im Repository statt auf einem Arbeitsplatzrechner.
Ja — sowohl GitHub als auch GitLab eignen sich. Versioniert wird der textuelle Export der SPS-Programme. GitLab bietet zusätzlich integrierte CI/CD-Pipelines, mit denen sich Export-Konsistenz, PLCSim-Tests und Compliance-Gates automatisieren lassen. GitHub Actions leistet dasselbe. Die Wahl hängt von der bestehenden Toolchain ab.
CODESYS bringt mit „CODESYS Git“ eine integrierte Git-Anbindung mit, die Projekte direkt aus der Entwicklungsumgebung committen und mergen kann. Die Bausteine werden dabei in einem versionierbaren Format abgelegt. Das macht CODESYS in puncto Git-Integration komfortabler als TIA Portal, das den Umweg über Openness braucht.
Spezialwerkzeuge wie octoplant (ehemals versiondog) und Copia Automation nutzen Git oft im Hintergrund, ergänzen es aber um herstellerübergreifende Unterstützung und PLC-spezifische, grafische Diffs — auch für Ladder-Logik. Sie sind sinnvoll, wenn mehrere Steuerungshersteller (Siemens, Rockwell, Beckhoff) parallel laufen oder im Team wenig Git-Know-how vorhanden ist. Wer volle Kontrolle und CI/CD-Tiefe will, fährt mit nativem Git über VCI oder Openness flexibler.
Comquent begleitet Fertigungs- und Automatisierungsunternehmen im DACH-Raum seit 2006 bei der Einführung von Versionierung und CI/CD, von der ersten Git-Struktur für SPS-Code bis zur automatisierten Pipeline. Fragen zu Ihrem konkreten TIA-Setup? Das Erstgespräch dauert 30 Minuten, kostet nichts und endet nicht in einer Angebots-PDF, sondern in zwei, drei konkreten nächsten Schritten für Ihr Projekt. Kontakt / Gespräch vereinbaren.
Wie geht es bei Ihnen mit TIA Portal und Git 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.
Warum Git die Grundlage für reproduzierbare SPS-Projekte ist — und wie der Einstieg gelingt.
Automatisierte Build-, Test- und Deploy-Pipeline für TIA-Portal-Projekte mit Jenkins.
Drei Pfade für C# in der OT — inklusive Git-Versionierung und CI/CD.