Library-Release-Workflow¶

Das PCS-Repository soll die Engineering Source of Truth bleiben. TIA Portal ist weiterhin wesentlich, aber hauptsächlich als Compiler, Integrationsumgebung und Simulations- oder Test-Runtime. Der Entwicklungsworkflow soll deshalb überall dort Git, die pcs CLI, automatisierte Checks, generierte Dokumentation und kontrollierte Release-Pakete verwenden, wo es sinnvoll möglich ist.

Release-Artefakte¶

Ein PCS-Release soll sowohl Source-Level- als auch TIA-Level-Artefakte enthalten.

Artefakt	Zweck
Git-Tag	Unveränderliche Referenz auf den freigegebenen Source-Stand
Source-Archiv	Nachvollziehbarkeit und Review der exakt exportierten PLC-Sources
Dokumentationsarchiv	System-, Integrations- und Release-Dokumentation
TIA Global Library	TIA-natives Lieferartefakt für Projektteams
TIA Library Archive	Komprimiertes Library-Paket für Distribution
Release-Manifest	Maschinenlesbare Release-Metadaten
Changelog	Menschenlesbare Zusammenfassung der Änderungen
Compatibility Notes	Migrations- und Update-Informationen für Integratoren

Bei TIA Portal Global Libraries verwendet die native Library-Datei die Erweiterung .al<version>, zum Beispiel .al20 für TIA Portal V20. Eine komprimierte archivierte Global Library verwendet .zal<version>, zum Beispiel .zal20.

releases/
  PCS_1.2.0/
    PCS_1.2.0.zal20
    PCS_1.2.0-source.zip
    PCS_1.2.0-docs.zip
    release-manifest.json
    changelog.md
    compatibility-notes.md
    checksums.txt

Die TIA Library ist das Lieferformat für Projektteams. Das Source-Archiv und der Git-Tag sind das Entwicklungs- und Traceability-Format.

Typen und Master Copies¶

TIA Libraries stellen zwei wichtige Wiederverwendungsmechanismen bereit:

Mechanismus	Empfohlene PCS-Nutzung
Types	Freigegebene PCS-Softwarebausteine, UDTs, Faceplates und andere wiederverwendbare versionierte Objekte
Master copies	Projekt-Scaffolding, Templates, Beispielstrukturen, Default-Objekte oder generierte Projektskelette

Verwende Types für freigegebene PCS-Produktlogik. Types können Versionen tragen und sind das richtige Konzept für verwaltete Library-Updates.

Verwende Master copies für Projekterstellung und Templates. Sie sind nützlich, wenn ein Projekt aus einer bekannten Struktur generiert werden soll, sollten aber nicht als Hauptmechanismus für Updates freigegebener PCS-Software behandelt werden.

Schutzstrategie¶

Freigegebene PCS Libraries sollen später als schreibgeschützte Library-Artefakte geliefert werden. Schreibschutz schützt das Release-Paket vor versehentlicher Änderung und hilft, Integratorprojekte an einer bekannten Produkt-Baseline auszurichten.

Know-how-Schutz ist ein separates Thema. Er schützt die Bausteinimplementierung selbst, nicht nur das Library-Artefakt. Für PCS sollte dies selektiv und später verwendet werden, nicht als Standardregel. In frühen Entwicklungs- und Integrationsphasen haben Transparenz, Troubleshooting und schnelles Lernen Vorrang.

Empfohlene Richtung:

Objekttyp	Schutzrichtung
Freigegebene Global Library	Schreibgeschütztes Lieferartefakt
Core-/interne Produktlogik	Kandidat für späteren selektiven Know-how-Schutz
Öffentliche UDTs und Schnittstellen	Bevorzugt lesbar
Interface-DBs und Parameterstrukturen	Bevorzugt lesbar
Projekt-Templates/Master Copies	Normalerweise lesbar

Das Entwickler-/Referenzprojekt und die Engineering Library sollen editierbar bleiben. Schutz gehört an die Release-Grenze, nicht in den täglichen Source-Deploy-Loop.

Entwicklerworkflow¶

Eine normale Entwicklungsänderung soll diesem Pfad folgen:

PCS library release workflow

PLC-Sources in tia/exports ändern.
Abhängige Bausteine, UDTs, DBs, HMI-Schnittstellen und Dokumentation aktualisieren.
In ein sauberes oder Referenz-TIA-Projekt deployen.
In TIA kompilieren.
Simulation, Validierung oder Regression Checks ausführen.
Diagramme rendern und Dokumentation bauen.
Ein Release nur erstellen, wenn das Referenzprojekt kompiliert und die Checks bestehen.

pcs deploy dry-run
pcs deploy no-compile
pcs deploy
pcs docs render
pcs docs build

Später soll daraus ein kontrollierter Release-Befehl werden:

pcs release prepare version=1.2.0
pcs release validate
pcs release library
pcs release package

Die aktuelle CLI stellt bereits die Prompt- und Packaging-Schicht bereit:

pcs release prepare version=1.2.0
pcs release validate
pcs release library version=1.2.0
pcs release package version=1.2.0

pcs release prepare erkennt geänderte PLC-Quelldateien aus Git, fragt, ob das Release breaking oder migrationsrelevant ist, und erstellt:

releases/PCS_1.2.0/
  release-manifest.json
  changelog.md
  compatibility-notes.md

pcs release package erstellt Source- und Dokumentationsarchive und schreibt checksums.txt.

pcs release library ist aktuell ein geführter Prompt. Der Befehl erstellt oder aktualisiert die TIA Global Library noch nicht automatisch. Die eigentliche TIA-Library-Erstellung braucht noch eine verifizierte Openness-Implementierung gegen eine echte Test-Library.

Standardmäßig sucht pcs release prepare nach dem vorherigen Release-Tag passend zu pcs-library-v* und vergleicht das neue Release mit dem neuesten niedrigeren Versionstag. Wenn zum Beispiel version=1.2.0 vorbereitet wird, verwendet der Befehl pcs-library-v1.1.0, falls dies das letzte vorherige PCS-Library-Tag ist.

Du kannst die Baseline explizit überschreiben:

pcs release prepare version=1.2.0 since=pcs-library-v1.0.0

Empfohlene Release-Tags:

pcs-library-v0.1.0
pcs-library-v0.2.0
pcs-library-v1.0.0

Automatisierungspotenzial¶

Das langfristige Ziel ist, dass normale PCS-Library-Release-Arbeit aus der PCS CLI oder GUI gesteuert werden kann, wobei TIA Portal über Openness als Compiler und Library-Backend verwendet wird.

Ziel für entwicklerseitige Automatisierung:

pcs deploy
pcs release prepare version=1.2.0
pcs release validate version=1.2.0
pcs release library version=1.2.0
pcs release package version=1.2.0

Ein zukünftiges pcs release library soll:

Das saubere/Referenz-TIA-Projekt öffnen.
Die Engineering Global Library öffnen oder erstellen.
Neue Versionen geänderter Library Types erstellen.
Bausteine und UDTs aus dem Referenzprojekt in die Library kopieren/aktualisieren.
Type-Versionen freigeben/finalisieren.
Eine archivierte .zal<version>-Delivery-Library erstellen.
Optional eine schreibgeschützte Delivery-Variante erstellen.
release-manifest.json und Checksummen aktualisieren.

Manuelle TIA-Schritte sind während der Lernphase akzeptabel, besonders solange das genaue Type-Version- und Schutzverhalten getestet wird. Sie sollen aber nicht der dauerhafte Zielworkflow sein.

Dependency Handling¶

Bausteinabhängigkeiten müssen als Teil des Release behandelt werden, nicht als manueller Nachgedanke. Wenn sich eine Bausteinschnittstelle ändert, kann das Release mehr als nur die geänderte Datei betreffen.

Beispiele:

Änderung	Mögliche Auswirkung
FB-Input/Output-Schnittstelle geändert	Aufrufer müssen aktualisiert werden
FB-`STAT`-Struktur geändert	Instance-DB-Layout kann sich ändern
UDT-Layout geändert	DBs, Bausteinparameter, HMI-Tags und Schnittstellen können betroffen sein
DB-Struktur geändert	HMI, Alarme, Trends, Simulation und externe Schnittstellen können betroffen sein
Symbol umbenannt	Aufrufer, HMI-Tags, Traces, Alarme und Dokumentation müssen möglicherweise aktualisiert werden

Kompilierung ist das erste harte Gate. Ein Release darf nicht aus einem Projekt erstellt werden, das nicht kompiliert.

Kompilierung allein reicht nicht aus. Der Release-Prozess soll auch Abhängigkeits- und Migrationsinformationen erfassen, damit Integratoren das Update-Risiko verstehen können.

FB_PMS changed
  depends on:
    UDT_PMSCommand
    UDT_PMSStatus
  used by:
    FB_PowerManagementCoordinator
    OB30_POWER_MANAGEMENT_20MS
  affects instance DBs:
    DB_PMS

Instance DBs¶

Instance DBs sind migrationssensitiv. Wenn sich eine FB-Schnittstelle oder ein STAT-Layout ändert, kann TIA den Instance DB bei der Kompilierung oft aktualisieren, aber das ist trotzdem ein Integrationsereignis.

Die Release Notes sollen Änderungen markieren, die Folgendes betreffen:

Instance-DB-Layout,
Startwerte,
Retain-Verhalten,
projektspezifische Parameter,
HMI-Bindings,
Online-Werte,
externe Schnittstellen.

Faustregel:

Änderungstyp	Release-Risiko
Nur interne Logik	Normalerweise Patch-Level
Schnittstellenänderung	Migrationsrelevant
`STAT`-Layoutänderung	Migrationsrelevant
UDT-Layoutänderung	Migrationsrelevant
DB- oder Symbolumbenennung	Hohes Integrationsrisiko

Zukünftiges `pcs release`¶

Der zukünftige Befehl pcs release soll ein reproduzierbares Paket erzeugen. Er soll nicht einfach archivieren, was zufällig in TIA geöffnet ist.

Erwartete Verantwortlichkeiten:

Sauberen Repository-Zustand prüfen oder lokale Änderungen explizit erfassen.
pcs.config.json validieren.
TIA-Openness-Tooling bauen.
Sources in ein sauberes Referenzprojekt deployen.
Kompilieren.
Validierungschecks ausführen.
Dokumentation bauen.
TIA Global Library erstellen oder aktualisieren.
Global Library als .zal<version> archivieren.
Release-Manifest, Changelog, Compatibility Notes und Checksummen generieren.

Beispielmanifest:

{
  "product": "PCS",
  "version": "1.2.0",
  "tiaVersion": "V20",
  "gitCommit": "abc123",
  "libraryArchive": "PCS_1.2.0.zal20",
  "changedBlocks": [
    "FB_PMS",
    "UDT_PMSStatus"
  ],
  "breakingChanges": true,
  "requiresProjectMigration": true
}

Designprinzip¶

Die freigegebene PCS Library soll sich wie eine Produktabhängigkeit verhalten. Das Repository erzeugt die Abhängigkeit, TIA kompiliert und validiert sie, und Projektteams konsumieren sie über einen kontrollierten Update-Workflow.

Das hält die PCS-Entwicklung nahe an moderner Softwareentwicklung, respektiert aber, dass das finale ausführbare Ziel weiterhin ein TIA-Portal-Projekt ist.

Revisionstabellen¶

Die Baustein-Header enthalten eine Revisionstabelle. Das kann teilweise automatisiert werden, soll aber kein blinder Bulk-Edit-Schritt werden.

Git kann erkennen, welche PLC-Quelldateien geändert wurden:

git status --short -- tia/exports

Damit könnte ein zukünftiger Befehl Revisionstabellen-Updates nur für geänderte Bausteine vorschlagen:

pcs revision preview
pcs revision update version=1.2.0 comment="Updated PMS interface"

Empfohlene Regel:

Git erkennt die betroffenen Dateien,
der Engineer schreibt den Engineering-Kommentar,
das Tool aktualisiert die Formatierung konsistent,
der Diff wird vor dem Release geprüft.

Der Kommentar ist Engineering-Absicht und soll menschlich formuliert bleiben. Das Tool kann bei Konsistenz helfen, soll aber keine Release-Kommentare aus dem Diff erfinden.

Referenzen¶

Siemens TIA Portal Dokumentation: Global Libraries verwenden .al<version>-Dateien, zum Beispiel .al20.
Siemens TIA Portal Dokumentation: archivierte komprimierte Global Libraries verwenden .zal<version>-Dateien, zum Beispiel .zal20.