Zum Inhalt

TIA-/Repo-Sync

Der langfristige Workflow soll Engineers weiterhin TIA Portal als vertraute Arbeitsumgebung geben, während Git die Source of Truth für PCS-Quelldateien bleibt.

Die Autorität im Repository ist:

tia/exports/**/*.scl
tia/exports/**/*.db
tia/exports/**/*.udt

TIA Portal wird als Arbeitskopie behandelt. Engineers dürfen in TIA bearbeiten und debuggen, aber Änderungen werden erst teamweit sichtbar, wenn der kontrollierte Export-/Check-in-Workflow sie zurück nach tia/exports schreibt und committet.

Sync-Modell

Die Sync-Engine vergleicht drei Zustände:

Zustand Bedeutung
Base Letzter bekannter synchronisierter Stand zwischen Repository und TIA
Repo Aktuelle Quelldateien unter tia/exports
TIA Aktuelle Bausteine, die aus dem geöffneten TIA-Projekt exportiert wurden

Daraus entstehen klare Entscheidungen:

Bedingung Interpretation
Base entspricht TIA, Repo geändert Eingehende Repository-Änderung, sicherer Kandidat für Import nach TIA
Base entspricht Repo, TIA geändert Lokale TIA-Änderung, sicherer Kandidat für Export ins Repository
Repo entspricht TIA Sauber
Base, Repo und TIA unterscheiden sich Konflikt, Engineer muss manuell prüfen

Der Vergleich basiert auf normalisierten Datei-Hashes, nicht auf Zeitstempeln. Zeilenenden werden vereinheitlicht, damit das Ergebnis echte Source-Änderungen zeigt.

Für SCL-Sources ignoriert die Normalisierung außerdem TIA-Portal-Formatierungen, die die Programmbedeutung nicht ändern:

  • optionale #-Präfixe bei lokalen Variablen, zum Beispiel _uiCounter und #_uiCounter,
  • TIA-generierte Metadatenzeilen wie TITLE = ... und S7_Optimized_Access.

Groß-/Kleinschreibung in quotierten Bezeichnern wird nicht ignoriert. Ein Unterschied wie "UDT_DRIVELIMITS" gegenüber "UDT_DriveLimits" bleibt sichtbar, weil er Coding Style und Source Ownership betrifft.

Für DB- und UDT-Sources werden Kommentare ignoriert, weil TIA-Source-Generierung sie nicht zuverlässig erhält.

Datenfluss

PCS TIA Sync Data Flow

PlantUML-Source: tia-repo-sync-flow.puml

Das Übersichtsdiagramm zeigt die persistenten Zustände. Die vereinfachten Sequenzdiagramme darunter zeigen den groben Ablauf zwischen Engineer, PCS GUI, PCS CLI, TIA Openness, TIA Portal, Repository und Git.

Vereinfachte Sequenz: Snapshot Und Status

PCS Sync - Simplified Snapshot And Status

PlantUML-Source: tia-sync-simple-snapshot-status.puml

Vereinfachte Sequenz: Repository Nach TIA

PCS Sync - Simplified Repository To TIA

PlantUML-Source: tia-sync-simple-repo-to-tia.puml

Vereinfachte Sequenz: TIA Nach Repository

PCS Sync - Simplified TIA To Repository

PlantUML-Source: tia-sync-simple-tia-to-repo.puml

Vereinfachte Sequenz: Baseline Und Git Publish

PCS Sync - Simplified Baseline And Git Publish

PlantUML-Source: tia-sync-simple-baseline-git.puml

Die detaillierten Sequenzdiagramme darunter zeigen den Datenfluss auf Befehlsebene für die wichtigsten Sync-Aktionen.

Snapshot Erfassen Und Status Aktualisieren

PCS Sync - Capture Snapshot And Refresh Status

PlantUML-Source: tia-sync-capture-status.puml

TIA Nach Repository

PCS Sync - TIA To Repository

PlantUML-Source: tia-sync-tia-to-repo.puml

Repository Nach TIA

PCS Sync - Repository To TIA

PlantUML-Source: tia-sync-repo-to-tia.puml

Baseline Aktualisieren

PCS Sync - Refresh Baseline

PlantUML-Source: tia-sync-baseline-refresh.puml

Der Sync-Workflow hat drei Zustände:

Zustand Gespeichert in Aktualisiert durch
Repository tia/exports VS-Code-Änderungen, Git Pulls oder SYNC TIA --> Repo
Base .pcs/sync/base-hashes.json REFRESH Baseline
TIA .pcs/sync/tia-snapshot/latest Capture TIA Snapshot

Die GUI-Buttons bewegen Daten zwischen diesen Zuständen:

Button Datenfluss Ergebnis
Capture TIA Snapshot TIA Portal -> TIA-Snapshot Aktuelle TIA-Bausteine werden als lokale vergleichbare Source-Dateien exportiert
Refresh Status Repository + Base + TIA-Snapshot -> Entscheidungstabelle Das Tool klassifiziert saubere Bausteine, sichere Sync-Kandidaten, Baseline-Kandidaten und Manual-Review-Einträge
SYNC Repo --> TIA Repository -> TIA Portal Ausgewählte Repository-Sources werden in die ausgewählte PLC deployed
SYNC TIA --> Repo TIA-Snapshot -> Repository Ausgewählte TIA-Snapshot-Sources werden nach tia/exports kopiert
SYNC Repo --> TIA --> Repo Repository -> TIA Portal, dann TIA-Snapshot -> Repository Beide ausgewählten Richtungen werden angewendet; Repository nach TIA läuft zuerst
REFRESH Baseline Repository -> Base Die aktuellen Repository-Vergleichshashes werden der neue lokale synchronisierte Stand

Die Baseline wird nicht in Git committet. Sie ist lokaler Workstation-Status und sollte nur aktualisiert werden, nachdem der Engineer verifiziert hat, dass Repository und TIA übereinstimmen.

TIA-bezogene Sync-Aktionen bevorzugen ein bereits geöffnetes passendes TIA-Portal-Projekt. Wenn das konfigurierte Projekt geöffnet ist, hängt sich PCS an diese laufende TIA-Instanz an und vermeidet den langsameren Startpfad. Wenn es nicht geöffnet ist, öffnet PCS das Projekt über Openness ohne Benutzeroberfläche.

Aktuelle Grundlage

Der erste Implementierungsschritt ist repository-seitiges Snapshotting:

pcs sync hash repo
pcs sync baseline
pcs sync status
pcs sync status --json
pcs sync snapshot tia plc=PLC_1
pcs sync diff FB_AlarmRouting

pcs sync baseline schreibt die lokale Baseline-Datei unter .pcs/sync. Dieser Ordner wird von Git ignoriert, weil er lokalen Workstation-Status und keine Projektquelle enthält.

Verwende die Baseline nur dann, wenn das aktuelle TIA-Projekt und die aktuellen Repository-Sources bekanntermaßen übereinstimmen:

pcs deploy
pcs sync baseline
pcs sync status

Wenn die Baseline bereits existiert und bewusst ersetzt werden soll:

pcs sync baseline --force

Erfasse den aktuellen TIA-Projektstand in einem lokalen Source-Snapshot:

pcs sync snapshot tia plc=PLC_1

Der Snapshot wird unter .pcs/sync/tia-snapshot/latest geschrieben. Er ist lokaler Workstation-Status und wird von Git ignoriert.

Sobald ein TIA-Snapshot vorhanden ist, vergleicht pcs sync status zusätzlich die Repository-Sources mit dem TIA-Snapshot:

Gruppe Bedeutung
Equivalent after source normalization Gleicher Source nach Ignorieren von Zeilenenden, Einrückungsrauschen, Leerzeilen und DB-/UDT-Kommentaren
Different between repo and TIA snapshot Derselbe Pfad existiert auf beiden Seiten, aber der Inhalt unterscheidet sich
Only in repo Source existiert in Git, aber nicht im TIA-Snapshot
Only in TIA snapshot Source existiert in TIA, ist aber nicht in tia/exports abgebildet

pcs sync status gibt zusätzlich eine Drei-Wege-Entscheidungsansicht über Base, Repo und TIA aus. Diese Ansicht soll die GUI für sichere Workflow-Entscheidungen verwenden:

Gruppe Bedeutung
Repo changed only Repository wurde geändert, während TIA noch Base entspricht; Kandidat für Repo -> TIA
TIA changed only TIA wurde geändert, während das Repository noch Base entspricht; Kandidat für TIA -> Repo
Same change in repo and TIA Repo und TIA stimmen überein, aber die Baseline ist alt; Kandidat für Baseline-Aktualisierung
Added in repo/TIA only Neue Source existiert nur auf einer Seite
Conflicts Repo und TIA wurden unterschiedlich geändert oder eine Seite wurde geändert, während die andere gelöscht wurde

Verwende einen fokussierten Diff für einen Baustein oder relativen Pfad:

pcs sync diff FB_AlarmRouting
pcs sync diff 06_ALARMS/FB_AlarmRouting.scl
pcs sync diff FB_AlarmRouting raw

Akzeptiere sichere reine TIA-Änderungen nach tia/exports:

pcs sync accept tia FB_AlarmRouting --dry-run
pcs sync accept tia FB_AlarmRouting
pcs sync accept tia all --dry-run
pcs sync accept tia all

Der Accept-Befehl kopiert nur Dateien aus Entscheidungsgruppen, die sichere TIA -> Repo-Kandidaten sind. Konflikte müssen zuerst manuell geprüft werden.

Aktueller GUI-Workflow

Die fokussierte GUI für diesen Workflow ist das PCS TIA Sync Tool:

.\tools\pcs-tia-sync-tool\build.ps1
.\tools\pcs-tia-sync-tool\bin\pcs-tia-sync-tool.exe

Es verwendet pcs sync status --json, zeigt eine gemeinsame Entscheidungstabelle für beide Richtungen und aktiviert nur Aktionen, die zur aktuellen Auswahl passen.

GUI-Gruppe Source-Entscheidung Aktion
TIA changed tiaChangedOnly, tiaAddedOnly TIA-Snapshot-Source nach tia/exports übernehmen
Repo changed repoChangedOnly, repoAddedOnly Repository-Source in die ausgewählte PLC deployen
Baseline sameChangeInRepoAndTia, addedSameInRepoAndTia, deletedInBoth Lokale Baseline nach Prüfung aktualisieren
Review conflicts, pathMismatches, einseitige Löschungen Manuelle Prüfung

Normaler GUI-Workflow:

  1. TIA-Snapshot erfassen.
  2. Summary-Kacheln und Änderungstabelle prüfen.
  3. Eine Zeile auswählen und bei Source-Unterschieden den Diff-Tab öffnen.
  4. Mit den Sync?-Checkboxes oder den Auswahlbuttons festlegen, welche sicheren Kandidaten enthalten sein sollen.
  5. Den violetten SYNC-Button klicken, um die ausgewählten Jobs auszuführen. Seine Beschriftung passt sich an die ausgewählte Richtung an: SYNC Repo --> TIA, SYNC TIA --> Repo oder SYNC Repo --> TIA --> Repo. Wenn beide Richtungen ausgewählt sind, laufen Repository -> TIA-Jobs zuerst, danach TIA -> Repository-Jobs.
  6. Baseline aktualisieren, wenn Repo und TIA übereinstimmen.

Die ältere Deployment-GUI bleibt für Deployment-Presets, Simulations-/Testarbeit und weitere Engineering-Helfer verfügbar. Die tägliche Source-Synchronisierung sollte aber pcs-tia-sync-tool.exe verwenden.

Manuelle Prüfung

Manuelle Prüfung bedeutet, dass der Drei-Wege-Vergleich keine sichere Richtung automatisch wählen kann. Der Engineer sollte zuerst den normalisierten Diff prüfen. Wenn der normalisierte Diff leer ist, handelt es sich wahrscheinlich um Formatierung oder TIA-Source-Generierungsrauschen; nach erneutem Status-Refresh kann eine Baseline-Aktualisierung ausreichen.

Wenn trotzdem eine echte Entscheidung nötig ist, bietet die GUI explizite Override-Aktionen für die ausgewählte Review-Zeile:

Override Verwenden, wenn
SYNC Repo --> TIA Die Repository-Source verbindlich ist und den TIA-Stand überschreiben soll
SYNC TIA --> Repo Die TIA-Snapshot-Source verbindlich ist und nach tia/exports kopiert werden soll

Bei reinen Formatierungsunterschieden ist Use Repo --> TIA die bevorzugte Override-Richtung, falls ein Override nötig ist, weil Git/Repository-Sources die Autorität bleiben.

Siehe auch: PCS Engineering Tools.

Nächste Implementierungsschritte

  1. Git-Buttons für Pull/Rebase, Commit und Push ergänzen.
  2. Konfliktprüfung und Side-by-side-Diffs für Änderungen am selben Baustein ergänzen.
  3. Nach Repo -> TIA-Deployment einen geführten Schritt "erneut Snapshot zur Verifikation erfassen" ergänzen.
  4. Die Commit-Vorbereitung nach TIA -> Repo-Übernahmen klarer führen.