TIA Portal mit Git
versionieren.
GitHub, GitLab & CI/CD.
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.
TIA-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. 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 dann 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 eigentliche Frage ist deshalb nicht, ob man versioniert, sondern was man versioniert. Da fängt die Arbeit an.
Warum SPS-Code selten in Git liegt
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: Versionsstände als Projekt_final_v3_NEU.zip auf Netzlaufwerken, kein Audit-Trail, keine nachvollziehbare Änderungshistorie — ein Problem für ASPICE, IEC 62443 und jede Funktionssicherheits-Argumentation. Genau hier setzt unser Anwendungsfall: CI/CD für SPS/PLC im Maschinenbau an — von der versionierbaren Codebasis bis zur durchgängigen Pipeline.
Drei Wege, SPS-/PLC-Code in Git zu bekommen
Alle drei Wege versionieren denselben textuellen Quelltext — sie unterscheiden sich im Integrationsgrad und im Aufwand. Welcher passt, hängt von TIA-Version, Team-Know-how und gewünschter CI/CD-Tiefe ab.
Version Control Interface (VCI)
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.
TIA Openness (Skript)
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.
Spezialwerkzeuge (octoplant, Copia)
Nutzen Git unter der Haube und liefern PLC-spezifische Diffs über mehrere Hersteller hinweg — sinnvoll, wenn Siemens, Rockwell und Beckhoff parallel laufen.
TIA Portal über Openness an Git anbinden
Der skriptbasierte Weg über die TIA-Openness-API — maximale Flexibilität für Custom-Toolchains und tiefe CI/CD-Integration, auch für ältere TIA-Versionen.
Openness-API aktivieren
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.
Projekt als Quelltext exportieren
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.
Git-Repository strukturieren
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.
Round-Trip absichern
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.
CI/CD-Pipeline anbinden
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.
Das TIA Portal Version Control Interface (VCI)
Das Version Control Interface (VCI) ist Siemens’ integrierte Brücke zwischen TIA-Portal-Engineering und Git. Ab V18 ist es Bestandteil des TIA Portal; ab V16 gibt es den VCI Git Connector als Add-In. Man arbeitet mit einem Workspace direkt im Engineering — ohne eigene Export-Skripte.
VCI-Workspace anlegen
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.
Objekte in den Workspace übernehmen
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.
Workspace mit Git verbinden
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.
Synchronisieren & CI/CD ergänzen
Ä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.
Git je TIA-Portal-Version
Ab welcher Version welcher Git-Weg verfügbar ist — und was V21 beim Export verbessert.
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 menschlich lesbaren Review taugte er aber kaum. Erst der Export von LAD/FBD/SCL in V21 macht aus „technisch versionierbar“ einen echten 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.
TIA Portal V20 und Git
In TIA Portal V20 ist das Version Control Interface fest integriert — der VCI-Workspace, der 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, Standard-Git-Diffs bleiben sperrig. Wer den textbasierten, direkt diff-fähigen LAD/FBD/SCL-Export will, braucht das Upgrade auf V21 — der Git-Workflow selbst bleibt beim Wechsel unverändert.
TIA Portal mit GitHub verbinden
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.
PLCSim in der Pipeline — die unbequeme Wahrheit
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.
Git-Integration je Engineering-Tool
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.
Wenn Git allein nicht reicht
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.
octoplant (ehem. versiondog)
Herstellerübergreifende Versionsverwaltung für Automatisierungsprojekte; interpretiert proprietäre Formate, stellt Ladder-/Grafik-Diffs dar und nutzt Git-Mechanismen (Branches, Rollback) im Hintergrund.
Copia Automation
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.
Kann man TIA Portal mit Git versionieren?
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.
Gibt es ein offizielles TIA Portal Git-Addin?
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.
Wie richtet man die TIA Portal Git Integration ein?
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.
Was ist das TIA Portal Version Control Interface (VCI)?
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.
Unterstützt TIA Portal Source Control bzw. Version Control?
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.
Openness oder VCI — welcher Weg ist der richtige?
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.
Was ist neu bei TIA Portal V21 in Sachen Git?
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.
Wie funktioniert die Versionsverwaltung in CODESYS?
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.
Was bedeutet „PLC Git“ und wie versioniert man PLC-Code mit Git?
„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.
Lässt sich SPS-Code mit GitHub oder GitLab versionieren?
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.
Warum reicht es nicht, die TIA-Portal-Projektdatei in Git zu legen?
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.
Was unterscheidet octoplant und Copia von nativem Git?
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 bei der Einführung von Versionierung und CI/CD für SPS-Code, von der ersten Git-Struktur bis zur automatisierten Pipeline. Fragen zu Ihrem konkreten TIA-Setup? Kontakt / Gespräch vereinbaren.
Verwandte Artikel
SPS Versionsverwaltung: Git für Industrial IT
Warum Git die Grundlage für reproduzierbare SPS-Projekte ist — und wie der Einstieg gelingt.
CI/CD für SPS: TIA Portal mit Jenkins automatisieren
Automatisierte Build-, Test- und Deploy-Pipeline für TIA-Portal-Projekte mit Jenkins.
SPS mit C# programmieren — S7.NET, TwinCAT.NET, CI/CD
Drei Pfade für C# in der OT — inklusive Git-Versionierung und CI/CD.
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