SIMATIC SD¶

SIMATIC SD ist Siemens' textbasiertes Dokumentformat zum Exportieren und Importieren von PLC-Bausteinen aus TIA Portal. Es ist für dieses Projekt interessant, weil es in dieselbe Richtung zeigt wie unser aktueller Workflow: Git als Source of Truth, VS Code als tägliche Edit-/Review-Umgebung und TIA Portal als Engineering- und Testumgebung.

Unser aktueller Workflow verwendet bereits TIA Portal Openness, um externe Quelldateien aus dem Repository zu importieren:

VS Code repo -> tia/exports/*.scl, *.db, *.udt -> pcs deploy -> TIA Portal

SIMATIC SD deutet eine mögliche zweite Spur an:

TIA Portal -> *.s7dcl, *.s7res -> Git review/commit -> TIA Portal import

Diese zweite Spur ist besonders relevant, wenn Bausteine grafisch in TIA Portal bearbeitet werden und später geprüft, committet oder zurück ins Repository synchronisiert werden sollen.

Formatübersicht¶

Laut Siemens TIA Portal V20 Dokumentation erzeugt ein SIMATIC-SD-Export zwei Textdateitypen:

Dateityp	Zweck
`.s7dcl`	Bausteindeklaration und Bausteincode
`.s7res`	Sprachabhängige Kommentare und Benutzertexte

Siemens beschreibt das Format als außerhalb von TIA Portal verwendbar, mit normalen Texteditoren editierbar, geeignet für Versionsverwaltungssysteme wie Git und geeignet zur Automatisierung von Engineering-Workflows.

Die .s7dcl-Datei enthält Bausteinattribute, Deklarationen und, wo anwendbar, Code. Bei LAD/KOP-Bausteinen werden grafische Netzwerke als Text dargestellt, mit Konstrukten wie NETWORK, RUNG, END_RUNG, Kontakten, Spulen, Verbindungen und Box-Aufrufen. Die .s7res-Datei speichert Kommentare und übersetzte Benutzertext-Ressourcen.

Bausteinidentität

SIMATIC SD ordnet Bausteine anhand des Bausteinnamens zu, der in der Textdatei enthalten ist. Siemens dokumentiert, dass die Bausteinnummer nicht in der .s7dcl-Datei gespeichert und beim Import von TIA Portal vergeben wird.

Siemens-Versionshinweise¶

Die Siemens-V20-Dokumentation beschreibt SIMATIC-SD-Export/-Import für S7-1200- und S7-1500-Bausteine mit wichtigen Einschränkungen:

Unterstützter Code-Export ist auf reine LAD/KOP-Bausteine begrenzt.
Datenbausteine und PLC-Datentypen sind ebenfalls exportierbar.
Mixed-language-Bausteine werden in diesem V20-Artikel nicht unterstützt.
Know-how-geschützte Bausteine sind ausgeschlossen.
Bestehende Bausteine oder PLC-Datentypen mit demselben Namen werden beim Import überschrieben.

Die Siemens-V21-Dokumentation scheint das Format zu erweitern. Sie dokumentiert SIMATIC SD für LAD/KOP- und FBD/FUP-Bausteine, einschließlich grafischer Bausteine, die SCL-Netzwerke enthalten. Sie sagt außerdem, dass AWL/STL nicht unterstützt wird und dass SCL-Bausteine keine Netzwerke importieren können, die in anderen Sprachen geschrieben sind.

Für dieses Projekt bedeutet das: Wir sollten SIMATIC-SD-Unterstützung als versionssensitiv behandeln. Das Tooling soll die aktive TIA-Portal-Version erkennen oder konfiguriert bekommen, bevor es annimmt, dass FBD/FUP oder gemischter grafischer/SCL-Netzwerkexport verfügbar ist.

Beziehung zu unserem aktuellen Source-Modell¶

Das Repository hält deploybare PLC-Sources aktuell unterhalb von tia/exports:

Repository-Source	Aktuelle Rolle
`.scl`	Primäre handbearbeitete Source für FB-, FC- und OB-Logik
`.db`	Datenbaustein-Source
`.udt`	PLC-Datentyp-Source

Das bleibt das einfachste Modell für code-first SCL-Entwicklung. SCL-Quelldateien sind lesbar, kompakt, gut diffbar und bereits durch unsere pcs CLI und Deployment-GUI unterstützt.

SIMATIC SD soll deshalb das aktuelle Source-Modell nicht sofort ersetzen. Ein besseres Nahziel ist, .scl, .db und .udt als primäre Source-Spur zu behalten und SIMATIC SD als Begleitspur für Fälle zu ergänzen, in denen die TIA-Portal-Bausteinrepräsentation wichtig ist.

Mögliches Repository-Layout:

tia/
  exports/
    00_SYSTEM/
      FC_0test.scl
    01_PLATFORM/
      UDT_LimitConfig.udt
  sd/
    00_SYSTEM/
      Some_LAD_Block.s7dcl
      Some_LAD_Block.s7res

Auswirkung auf ein reines SCL-Projekt¶

Wenn dieses Projekt SCL-only bleibt, nutzen wir die stärkste Funktion von SIMATIC SD nicht. Der größte praktische Wert von SIMATIC SD ist, dass grafische LAD/KOP- und FBD/FUP-Bausteine als Textdateien dargestellt, in Git geprüft und zurück nach TIA Portal importiert werden können.

Für reines SCL ist unser bestehender .scl-External-Source-Workflow normalerweise besser:

Er ist einfacher.
Er ist bereits implementiert.
Er lässt sich natürlich in VS Code bearbeiten.
Er vermeidet zusätzliche .s7res-Ressourcendateien, solange wir keine mehrsprachige Benutzertext-Behandlung brauchen.
Er hält Diffs auf den Source-Code fokussiert, den wir tatsächlich schreiben.

SIMATIC SD kann in einem SCL-lastigen oder SCL-only-Projekt trotzdem nützlich sein für:

Export von in TIA erstellten Datenbausteinen oder PLC-Datentypen in einem TIA-nativen Textformat.
Vergleich dessen, was TIA Portal intern hat, mit dem, was das Repository erwartet.
Erhaltung von Bausteinmetadaten, die externe .scl-Source-Generierung möglicherweise nicht so direkt ausdrückt.
Vorbereitung auf eine Zukunft, in der Diagnose-, Interlock- oder Commissioning-Logik bewusst in LAD/FBD geschrieben wird.
Unterstützung eines Workflows "TIA wurde zuerst geändert, Git zieht nach".

Die kurze Antwort ist also: Für reines SCL ist SIMATIC SD als Haupt-Autorenformat nicht besonders spannend. Für grafische Programmiersprachen und für Roundtrip-Synchronisierung von TIA zurück nach Git wird es deutlich mächtiger.

VS-Code-Potenzial¶

Die Visual-Studio-Code-Erweiterung Dynamic Siemens Language Support ist wichtig, weil sie Siemens-Dateien als echten Entwicklungsworkspace behandelt und nicht nur als Plain Text.

Die Marketplace-Seite listet Unterstützung für:

Siemens SCL / Structured Text Language Tooling.
.s7dcl- und .s7res-Dateizuordnungen.
FBD-Bausteinvorschau aus .s7dcl-Dateien.
Inlay Hints und Navigation zwischen .s7dcl-Referenzen und .s7res-Textressourcen.
Workspace-Typ-Scoping über .plc.json.
Siemens-Projektbibliotheks-Metadatenunterstützung.
.scltest-Testunterstützung.

Das bedeutet, dass ein SIMATIC-SD-Workflow in VS Code reviewbar und teilweise visuell werden könnte. Ein Engineer könnte einen grafischen Baustein aus TIA Portal exportieren, den textuellen .s7dcl-Diff in Git prüfen und die Extension-Vorschau nutzen, um die Bausteinstruktur zu verstehen, ohne für jedes Review TIA öffnen zu müssen.

Möglicher PCS-Workflow¶

Die interessante langfristige Form ist bidirektional:

Normal code-first work:

edit in VS Code
  -> pcs deploy
  -> TIA Portal imports/generates
  -> compile/test in TIA

TIA-first debugging or commissioning work:

edit/debug in TIA Portal
  -> pcs sync tia-to-repo
  -> Git diff in VS Code
  -> review/commit

Mögliche zukünftige Befehle:

pcs sync tia-to-repo blocks=FB_MotorControl
pcs sync tia-to-repo folder=06_ALARMS
pcs sync repo-to-tia blocks=Some_LAD_Block
pcs diff tia blocks=FB_MotorControl

Die erste nützliche Implementierung wäre wahrscheinlich export-only:

Verbindung zum konfigurierten TIA-Portal-Projekt über Openness herstellen.
Ausgewählte PLC-Bausteine per Name oder Ordner finden.
Sie als SIMATIC-SD-Dokumente in einen Staging-Ordner exportieren.
Den Staging-Export gegen tia/sd vergleichen.
Git den tatsächlichen Diff anzeigen lassen.

Das würde das reale Commissioning-Szenario unterstützen:

Ein Engineer ändert während des Debuggings einen Baustein in TIA Portal und möchte die Änderung danach zurück ins Repository bringen und über VS Code committen.

Risiken und offene Fragen¶

Bevor SIMATIC SD als erstklassiges Source-Format eingeführt wird, sollten wir diese Fragen mit kleinen echten Bausteinen testen:

Stellt Openness Import-/Exportmethoden über unsere Ziel-TIA-Portal-Version hinweg konsistent bereit?
Sind .s7dcl-Exporte stabil genug für saubere Git-Diffs, oder sortiert TIA Metadaten häufig um?
Wie werden Kommentare, Netzwerktitel, mehrsprachiger Text und generierte Identifikatoren in .s7res dargestellt?
Was passiert, wenn eine Bausteinnummer in einem bestehenden Projekt wichtig ist, da die .s7dcl-Datei per Name zuordnet?
Können wir aktuelle externe Source-Generierung und SIMATIC-SD-Import sicher in einem Projekt mischen?
Wie verhindern wir versehentliches Überschreiben eines TIA-Bausteins mit demselben Namen?
Funktioniert die VS-Code-Extension-Vorschau gut genug für Engineering-Reviews unseres tatsächlichen Bausteinstils?

Empfehlung¶

Behalte .scl, .db und .udt vorerst als primäres Source-Format. Sie passen zur aktuellen SCL-first-Architektur und werden bereits vom pcs-Deployment-Tooling unterstützt.

Ergänze SIMATIC SD experimentell als Synchronisierungs- und grafische-Baustein-Spur:

Verwende es, wenn ein Baustein bewusst in LAD/FBD erstellt oder gepflegt wird.
Verwende es für TIA-to-repo-Synchronisierung nach Debugging- oder Commissioning-Änderungen.
Verwende es als Brücke Richtung zukünftiges Library Management.
Mache es nicht zum Standard-SCL-Autorenformat, außer es zeigt einen konkreten Vorteil gegenüber einfachem .scl.

So bekommen wir den praktischen Nutzen, ohne das Repository komplexer zu machen als nötig.