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.
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 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 Ä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.
Warum liegt SPS-Code so selten in Git?
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.
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.
AIDrei Wege, SPS-/PLC-Code in Git zu bekommen
Die Frage, die uns in Erstgesprächen am häufigsten gestellt wird, lautet nicht ob, sondern womit: VCI, Openness oder gleich ein Spezialwerkzeug. Und 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 am Ende brauchen. Die ersten beiden Punkte klären die zwei Fragen unten in zwanzig Sekunden.
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.
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?
AIWas ist das Version Control Interface (VCI) im TIA Portal?
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.
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.
Welcher Git-Weg steht in welcher TIA-Portal-Version zur Verfügung?
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 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. Dafür lohnt sich der Weg: Der Moment, in dem das erste Review einen Baustein-Fehler vor der Inbetriebnahme fängt statt danach, ist in unseren Projekten regelmäßig der Punkt, an dem aus Skepsis im Team Überzeugung wird.
Braucht das Version Control Interface einen Download?
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 — VS Code, Git Bash oder die IDE Ihrer Wahl. Wie Sie das Repository darüber hinaus strukturieren — und wo OT-Speziallösungen wie octoplant oder versiondog statt Standard-Git die bessere Wahl sind —, vertieft unser Beitrag zur SPS-Versionsverwaltung mit octoplant, versiondog und Git; die Begriffe rund um das TIA Portal als Engineering-Framework klärt der Glossar-Eintrag.
TIA Portal V21 und Git: was der LAD/FBD/SCL-Export ändert
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.
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.
Wie richte ich das erste Git-Repository für TIA Portal V21 ein?
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.
Ein Hinweis vorweg, weil er in der Praxis Zeit spart: 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.
Leeres Workspace-Verzeichnis anlegen
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.
git init und .gitignore vor dem ersten Export
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.
VCI-Workspace daraufsetzen und Bausteine übernehmen
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).
Ersten Commit setzen und den Stichtag festschreiben
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.
Was gehört in die .gitignore eines TIA-Repositories?
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/Wie strukturiert man das Repository?
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.xmlDie Befehle für den ersten Commit
Mehr 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
Was sind SIMATIC Source Documents (SIMATIC SD)?
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: Der Aufbau oben bleibt identisch. Verzeichnisstruktur, .gitignore, Commit-Disziplin und die spätere CI/CD-Anbindung ändern sich beim Upgrade nicht, nur die Diffs werden lesbar. Wer heute anfängt, verliert also nichts, wenn V21 erst nächstes Jahr kommt. Wer dagegen auf das Upgrade wartet, bevor überhaupt ein Repository existiert, verschenkt genau die Zeit, in der die Historie hätte wachsen können.
Das Repository steht.
Und dann?
Die vier Schritte oben schaffen Sie an einem Nachmittag. Länger dauert die Frage danach. Welche Bausteine wandern zuerst in den Workspace, ab wann gilt der Git-Stand verbindlich, und wie ziehen die Kollegen mit, die seit zwölf Jahren mit dem Netzlaufwerk arbeiten? Darüber sprechen wir an Ihrem Projekt, nicht an einer Beispielstruktur.
kein Vertriebsgespräch
TIA Portal über Openness an Git anbinden
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.
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.
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. Welches SPS-Vergleichstool zu welchem Hersteller passt — und wie Sie zwei SPS-Programme vergleichen, ordnet der Hersteller-Überblick ein.
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.
Gibt es ein Git-Add-In, das direkt aus dem TIA Portal heraus committet?
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.
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.
Wie lege ich das erste Git-Repository für ein TIA-Portal-Projekt an?
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.
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.
Wo finde ich das Version Control Interface im TIA Portal — braucht es einen Download?
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.
Funktioniert das Version Control Interface auch mit Subversion (SVN) statt Git?
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.
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.
Gibt es das Version Control Interface schon in TIA Portal V19?
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.
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.
Was sind SIMATIC Source Documents (SIMATIC SD) in TIA Portal V21?
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.
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.
Ist Git für SPS-Programmierer schwer zu erlernen?
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.
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 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.
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