Skip to content

SIMATIC SD

SIMATIC SD is Siemens' text-based document format for exporting and importing PLC blocks from TIA Portal. It is interesting for this project because it points in the same direction as our current workflow: Git as the source of truth, VS Code as the daily edit/review environment, and TIA Portal as the engineering and test environment.

Our current workflow already uses TIA Portal Openness to import external source files from the repository:

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

SIMATIC SD suggests a possible second lane:

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

That second lane is especially relevant when blocks are edited graphically in TIA Portal and should later be reviewed, committed, or synchronized back into the repository.

Format Overview

According to the Siemens TIA Portal V20 documentation, a SIMATIC SD export creates two text file types:

File type Purpose
.s7dcl Block declaration and block code
.s7res Language-dependent comments and user texts

Siemens describes the format as usable outside TIA Portal, editable with normal text editors, suitable for version control systems such as Git, and suitable for automating engineering workflows.

The .s7dcl file contains block attributes, declarations, and code where applicable. For LAD/KOP blocks, graphical networks are represented as text using constructs such as NETWORK, RUNG, END_RUNG, contacts, coils, wires, and box calls. The .s7res file stores comments and translated user text resources.

Block identity

SIMATIC SD maps blocks by the block name contained in the text file. Siemens documents that the block number is not stored in the .s7dcl file and is assigned by TIA Portal during import.

Siemens Version Notes

The Siemens V20 documentation describes SIMATIC SD export/import for S7-1200 and S7-1500 blocks, with important restrictions:

  • Supported code export is limited to pure LAD/KOP blocks.
  • Data blocks and PLC data types are also exportable.
  • Mixed-language blocks are not supported in that V20 article.
  • Know-how-protected blocks are excluded.
  • Existing blocks or PLC data types with the same name are overwritten on import.

The Siemens V21 documentation appears to broaden the format. It documents SIMATIC SD for LAD/KOP and FBD/FUP blocks, including graphical blocks that contain SCL networks. It also states that AWL/STL is not supported, and that SCL blocks cannot import networks written in other languages.

For this project, that means we should treat SIMATIC SD support as version-sensitive. The tooling should detect or be configured for the active TIA Portal version before assuming that FBD/FUP or mixed graphical/SCL network export is available.

Relation To Our Current Source Model

The repository currently keeps deployable PLC sources below tia/exports:

Repository source Current role
.scl Primary hand-edited source for FB, FC, and OB logic
.db Data block source
.udt PLC data type source

This remains the simplest model for code-first SCL development. SCL source files are readable, compact, easy to diff, and already supported by our pcs CLI and deployment GUI.

SIMATIC SD should therefore not replace the current source model immediately. A better near-term model is to keep .scl, .db, and .udt as the primary source lane, and add SIMATIC SD as a companion lane for cases where TIA Portal's block representation matters.

Possible 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

SCL-Only Project Impact

If we keep this project SCL-only, we do not use the strongest feature of SIMATIC SD. The biggest practical value of SIMATIC SD is that graphical LAD/KOP and FBD/FUP blocks can be represented as text files, reviewed in Git, and imported back into TIA Portal.

For pure SCL, our existing .scl external source workflow is usually better:

  • It is simpler.
  • It is already implemented.
  • It is natural to edit in VS Code.
  • It avoids extra .s7res resource files unless we need multilingual user text handling.
  • It keeps diffs focused on the source code we actually write.

SIMATIC SD can still be useful in an SCL-heavy or SCL-only project for:

  • Exporting TIA-authored data blocks or PLC data types in a TIA-native text format.
  • Comparing what TIA Portal has internally against what the repository expects.
  • Preserving block metadata that external .scl source generation may not express as directly.
  • Preparing for a future where some diagnostic, interlock, or commissioning logic is intentionally written in LAD/FBD.
  • Supporting a "TIA changed first, Git catches up" workflow.

So the short answer is: for pure SCL, SIMATIC SD is not very exciting as the main authoring format. For graphical programming languages, and for round-trip synchronization from TIA back to Git, it becomes much more powerful.

VS Code Potential

The Visual Studio Code extension Dynamic Siemens Language Support is important because it treats Siemens files as a real development workspace rather than plain text only.

The Marketplace page lists support for:

  • Siemens SCL / Structured Text language tooling.
  • .s7dcl and .s7res file associations.
  • FBD block preview from .s7dcl files.
  • Inlay hints and navigation between .s7dcl references and .s7res text resources.
  • Workspace type scoping through .plc.json.
  • Siemens project library metadata support.
  • .scltest testing support.

That means a SIMATIC SD workflow could become reviewable and partly visual in VS Code. An engineer could export a graphical block from TIA Portal, inspect the textual .s7dcl diff in Git, and use the extension preview to understand the block structure without opening TIA for every review.

Potential PCS Workflow

The interesting long-term shape is bidirectional:

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

Possible future commands:

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

The first useful implementation would probably be export-only:

  1. Connect to the configured TIA Portal project through Openness.
  2. Find selected PLC blocks by name or folder.
  3. Export them as SIMATIC SD documents into a staging folder.
  4. Compare the staged export against tia/sd.
  5. Let Git show the actual diff.

That would support the real commissioning scenario:

An engineer changes a block in TIA Portal during debugging, then wants to bring the change back into the repository and commit it through VS Code.

Risks And Open Questions

Before adopting SIMATIC SD as a first-class source format, we should test these questions with small real blocks:

  • Does Openness expose import/export methods consistently across our target TIA Portal version?
  • Are .s7dcl exports stable enough for clean Git diffs, or does TIA reorder metadata often?
  • How are comments, network titles, multilingual text, and generated identifiers represented in .s7res?
  • What happens when a block number matters in an existing project, since the .s7dcl file maps by name?
  • Can we safely mix current external source generation and SIMATIC SD import in one project?
  • How should we prevent accidental overwrite of a TIA block with the same name?
  • Does the VS Code extension preview work well enough for engineering review of our actual block style?

Recommendation

Keep .scl, .db, and .udt as the primary source format for now. They fit the current SCL-first architecture and are already supported by the pcs deployment tooling.

Add SIMATIC SD experimentally as a synchronization and graphical-block lane:

  • Use it when a block is intentionally authored or maintained in LAD/FBD.
  • Use it for TIA-to-repo synchronization after debugging or commissioning edits.
  • Use it as a bridge toward future library management.
  • Avoid making it the default SCL authoring format unless it proves a concrete advantage over plain .scl.

This gives us the practical benefit without making the repo more complex than it needs to be.

Resources