Recovering Know-How Protected SCL Blocks in STEP 7 and TIA Portal

When an SCL source file is compiled into a know-how protected FB, FC, DB, or UDT, the human-readable source is discarded. The compiled block persists, but only as opaque machine code that the editor disassembles into STL on demand. The block interface (inputs, outputs, in-outs, stat, temp) is preserved, so the program still calls and executes the block, but the algorithm is no longer editable as SCL. This article documents the Siemens-supported recovery paths, the official procedure to open a protected block in TIA Portal V20, the upgrade workflow for know-how protected blocks, the standard FC105/FC106 scaling blocks that often replace lost custom blocks, and the engineering practices that prevent the source from being lost in the first place.

1. The Know-How Protection Compromise in SIMATIC

Know-how protection in SIMATIC controllers is implemented at the editor level, not the CPU firmware level. The protection serves two purposes: it prevents an unauthorized user from reading the algorithm inside the block, and it allows an OEM to ship a runtime library to an end customer without disclosing the implementation. The mechanism is the same across S7-300, S7-400, S7-1200, and S7-1500:

• The SCL compiler emits MC7 machine code for the CPU plus an STL disassembly for the editor.
• The block body is encrypted; the editor cannot display SCL, LAD, or FBD after protection is applied.
• Comments, network titles, and symbolic names from the original SCL source are stripped from the body. They are not preserved in any recoverable form.
• The block interface (IN, OUT, IN_OUT, STAT, TEMP) is retained and visible to anyone with project access, even before the password is entered.
• The protection is enforced by STEP 7 or TIA Portal; the CPU itself executes the block identically to an unprotected block.

The trade-off is that the original SCL source is destroyed the moment the block is compiled with know-how protection enabled. The only round-trippable copy of the SCL lives in the Source Files container (STEP 7 V5.x) or the External source files of the project (TIA Portal). Lose that source, and the only paths back to editable SCL are backup, source control, or rebuild from the interface.

2. SCL-to-STL Compilation: Why the Source Is Lost

SCL is a PASCAL-style high-level language. Before the introduction of the SCL compiler with TIA Portal V13, the SCL compilation pipeline was:

SCL source → SCL compiler → MC7 code (CPU-executable) + STL disassembly (editor view)

In TIA Portal V14 and later, the SCL compiler emits optimized MC7 plus a high-level SCL skeleton, but the body inside the protected region is still a compiled artifact. The consequences for an engineer who has only the compiled block are:

• Variable names are gone. STL shows absolute or symbolic addresses resolved at compile time. Local TEMP and STAT data appear as LW/T, LD/T, or as DBW/DBB references inside an instance DB.
• Control structures are flattened. WHILE, CASE, FOR, REPEAT, and IF-THEN-ELSIF become a network of JU, JC, JL, and TAR instructions with temporaries holding intermediate Boolean results.
• The CALL interface is preserved only as a header. Inputs and outputs are visible at the call site, but the body inside is opaque.
• Floating-point literals and arithmetic precision are preserved. A short algorithm with standard FC/FB calls can be re-engineered from STL if you know what the block is supposed to do.

The pragmatic engineering answer is to rewrite the block from its interface contract rather than try to decompile the STL. For complex blocks this can take hours; for blocks containing a one-line error, finding it in the decompiled STL can take days. The deciding factor is almost always do you have the interface documentation?

3. STEP 7 V5.x: Procedure to Open a Protected Block

In STEP 7 V5.4 through V5.6 (SIMATIC Manager, S7-300/400), the procedure to inspect a protected block is documented in the STEP 7 online help. The steps are:

1. Open SIMATIC Manager and the S7 program containing the protected block.
2. Navigate to the Blocks container in either the offline or online view.
3. Right-click the protected FB, FC, DB, UDT, or OB and select Object Properties to confirm the author, time stamp, and version. This metadata is often the only breadcrumb available when the source is lost.
4. Double-click the block. The Access Protection dialog opens and prompts for the password that was set when the block was protected.
5. Enter the correct password and confirm. The editor opens the block in STL view, not in the original SCL. Comments and network titles are not restored.

For S7-300/400 systems, Siemens recommends storing the SCL source in the Sources container of the S7 program. The Sources container is the only place where the editable, round-trippable SCL persists across compile operations. When you compile a source, STEP 7 generates the block; when you change the source, you re-compile. Without the source file, you only have the compiled object.

4. TIA Portal V17 to V20: Procedure to Open a Protected Block

In TIA Portal, the procedure is similar but uses the project tree and is documented in the TIA Portal V20 knowledge base at Opening know-how protected blocks. The steps are:

1. Open the TIA Portal project.
2. In the project tree, expand the PLC station and open the Program blocks folder.
3. Select the protected FB, FC, or DB. The protected block icon shows a small lock overlay in the project tree.
4. Double-click the block. The editor opens the block. If the block is know-how protected, the Access protection dialog opens and prompts for the password.
5. Enter the password and confirm. The editor displays the block in the language that was active at compile time. For SCL blocks, this is typically an SCL skeleton with the body hidden.

Per the official TIA Portal V20 documentation, the protected section of the block cannot be edited or viewed even after the correct password is entered, unless the protection is removed. To remove protection, the original author must clear the password in the block properties and recompile the source. The password protects the block content, not just the block opening; entering the password allows you to read the interface and use the block, but not to see or modify the protected body.

For SCL blocks specifically, TIA Portal stores the source SCL separately from the compiled block when you add the block to the project tree. The compiled block resides in the PLC station; the source resides in the External source files of the project. Removing the source from the project does not remove the compiled block, but it does mean the engineer can no longer edit and recompile the source — they can only re-engineer it from the interface.

5. Upgrading Know-How Protected Blocks Between TIA Portal Versions

When you upgrade a project from one TIA Portal version to another (for example, V17 to V20), the compiler re-creates the block body in the new version. For unprotected blocks, this is a transparent recompile. For know-how protected blocks, the upgrade behavior is documented in the TIA Portal V20 knowledge base at Upgrading know-how protected blocks. The expected behavior is:

• The know-how protection password is preserved across the upgrade.
• The compiled block body is upgraded to the new MC7-equivalent representation for the target CPU firmware.
• The block is re-protected automatically with the same password after the upgrade.
• The External source files are also upgraded; protected source files retain their protection.

The official TIA Portal V20 documentation explicitly states that after the upgrade the engineer must verify the know-how protection is correctly applied to each block. The recommended procedure is:

1. Upgrade the project as usual using the project upgrade wizard.
2. Compile the software (PLC → Software (rebuild all blocks) or right-click the program blocks → Compile).
3. Open the protected block and verify that the Access protection dialog appears.
4. If the block is no longer protected (rare, but possible if a custom library supplied the block and the upgrade path dropped the protection), re-apply the know-how protection in the Edit menu using the Know-how protection command.

The official Siemens documentation states: "Set up the know-how protection of the blocks from the current product version again in the 'Edit' menu with the 'Know-how protection' command." This is the post-upgrade verification step, and skipping it leaves the block exposed.

6. S7-300/400 vs S7-1500: Differences in Protection Behavior

The S7-1500 generation (CPU firmware V1.8 and later, TIA Portal V14 SP1 and later) introduced additional protection features that the S7-300/400 do not have. The table below summarizes the differences that affect recovery work.

For S7-300/400 with STEP 7 V5.x, the know-how password is stored in the block's internal header in an XOR-obfuscated form. For S7-1500 with TIA Portal V14+, the password is hashed with SHA-256. The implication for the engineer: if you are working on S7-1500 and lose the source, you cannot easily decompile or debug the block. The only recovery paths are the same as for S7-300/400 — recover from backup, source control, or rebuild from the interface.

7. The Pragmatic Recovery Path: Rebuild from the Interface

When the source is genuinely lost, the most efficient recovery is to rebuild the block from its interface. The interface is the contract the block exposes to the rest of the program, and it is preserved even when the block is know-how protected. The rebuild workflow is:

1. Document the interface. Open the block properties in STEP 7 / TIA Portal and copy the IN, OUT, IN_OUT, STAT, and TEMP variables with their data types and initial values. In TIA Portal, the interface editor is visible even on protected blocks.
2. Identify the block type. FB, FC, DB, or UDT determines whether there is an instance DB that holds STAT data. For FBs, the instance DB layout gives you the persistent state between calls.
3. Trace the call sites. Cross-reference the block in the program (right-click → Go to usage in TIA Portal, or Cross-references in STEP 7 V5.x). The call sites tell you what the block is supposed to do.
4. Re-implement from the standard library. If the protected block was a custom scaling block, the simplest fix is often to replace it with FC105/FC106 plus a wrapper for alarm limits.
5. Test against the original. If you have a trace recording or a process historian that captured the block's behavior, replay the inputs and compare the new block's outputs to the recorded outputs.
6. Add version control. Place the rebuilt source in a version control system (SVN, Git, or TIA Portal's project library versioning) before deploying.

8. FC105 SCALE and FC106 UNSCALE: The Standard Replacements

The most common custom block in STEP 7 V5.x projects is an analog scaling block with alarm limits. Siemens ships the standard FC105 (SCALE) and FC106 (UNSCALE) blocks specifically for this purpose. Both are documented in the STEP 7 Standard Library, in the path Libraries → Standard Library → TI-S7 Converting Blocks.

Key behaviors of FC105:

• For unipolar input (BIPOLAR = FALSE), the input range is 0 to 27648.
• For bipolar input (BIPOLAR = TRUE), the input range is −27648 to +27648, mapped linearly to LO_LIM to HI_LIM.
• If IN is outside the expected range, the output is clamped to LO_LIM or HI_LIM and RET_VAL carries W#16#0008 (overflow) or W#16#0007 (underflow).
• RET_VAL is W#16#0000 on success.

Alarm handling is not in FC105. If the original protected block was FC105 plus alarm comparators, the rebuild is straightforward: call FC105, then compare the OUT to your alarm thresholds with hysteresis. A typical alarm block in SCL is shown in the next section.

9. SCL Source Example: A Drop-In Scaling Block with Alarms

For an analog-input scaling block, the SCL replacement is typically ten to twenty lines. The example below implements a scaling block with low and high alarm flags and hysteresis. It compiles in S7-300/400 (STEP 7 V5.5 and later) and S7-1200/1500 (TIA Portal V13 and later).

FUNCTION_BLOCK FB_ScaleAlarm
VAR_INPUT
  iRaw       : INT;    // 0..27648 (unipolar) or +/-27648 (bipolar)
  bBipolar   : BOOL;   // TRUE for bipolar input range
  rLow       : REAL;   // engineering low (e.g. 0.0 for 0 degC)
  rHigh      : REAL;   // engineering high (e.g. 100.0 for 100 degC)
  rAlarmLo   : REAL;   // low alarm threshold (e.g. 5.0)
  rAlarmHi   : REAL;   // high alarm threshold (e.g. 95.0)
  rHyst      : REAL;   // alarm hysteresis (e.g. 1.0)
END_VAR
VAR_OUTPUT
  rEng       : REAL;   // engineering value
  bAlarmLo   : BOOL;   // low alarm active
  bAlarmHi   : BOOL;   // high alarm active
  wStatus    : WORD;   // W#16#0000 = OK, W#16#0007 = underflow, W#16#0008 = overflow
END_VAR
VAR
  rRange     : REAL;
  rNorm      : REAL;
END_VAR
BEGIN
  rRange := rHigh - rLow;
  IF rRange <= 0.0 THEN
    rEng := rLow;
    bAlarmLo := TRUE;
    bAlarmHi := TRUE;
    wStatus := W#16#0001; // configuration error
    RETURN;
END_IF;

IF bBipolar THEN
  rNorm := INT_TO_REAL(iRaw) / 27648.0;
ELSE
  rNorm := INT_TO_REAL(iRaw) / 27648.0;
  IF rNorm < 0.0 THEN rNorm := 0.0; END_IF;
END_IF;

rEng := rNorm * rRange + rLow;

// Limit check
IF iRaw > 27648 THEN
  wStatus := W#16#0008;
ELSIF (bBipolar AND iRaw < -27648) OR (NOT bBipolar AND iRaw < 0) THEN
  wStatus := W#16#0007;
ELSE
  wStatus := W#16#0000;
END_IF;

// Alarms with hysteresis (sticky until clear)
IF rEng < (rAlarmLo + rHyst) THEN
  bAlarmLo := TRUE;
ELSIF rEng > (rAlarmLo + 2.0 * rHyst) THEN
  bAlarmLo := FALSE;
END_IF;

IF rEng > (rAlarmHi - rHyst) THEN
  bAlarmHi := TRUE;
ELSIF rEng < (rAlarmHi - 2.0 * rHyst) THEN
  bAlarmHi := FALSE;
END_IF;
END_FUNCTION_BLOCK

This SCL block can be compiled and dropped in as a functional replacement for many custom scaling blocks. Note that this is an example, not a drop-in FC105 replacement; FC105 has additional behaviors (e.g., bipolar offset handling) that you must preserve if the original block used them. If the original block called FC105 internally, the rebuild can simply call FC105 and post-process the OUT to drive the alarm flags.

10. Prevention: Source Management for SCL Blocks

The single most effective prevention is to store the SCL source in a version control system and never let the only copy live inside the offline program of a project. The following practices are field-proven across hundreds of STEP 7 and TIA Portal projects.

1. External source files. In STEP 7 V5.x, SCL sources are stored in the Sources container. In TIA Portal, they live in External source files. Both can be exported to .scl text files on disk.
2. Project library. TIA Portal master copies and project libraries allow you to version a block separately from the program. This is the supported Siemens mechanism for re-using protected blocks across projects.
3. Global libraries. TIA Portal global libraries (.al* files) are importable across projects and across TIA Portal versions. A know-how protected block in a global library is shipped as compiled code; the source stays with the author.
4. Source control outside TIA Portal. Export the SCL source as plain text and check it into Git, SVN, or a vendor-neutral PLM. Commit on every compile. Tag releases with the deployed program version.
5. PDF listings. For audit-trail purposes, generate a PDF of the SCL source with comments and check it into a document management system. A PDF survives even when the project file is lost.
6. Backup policy. The offline program on the engineering station is not a backup. Keep a separate backup of the project on a network share or NAS with retention of at least ten revisions.
7. Password vault. Store the know-how protection password in a corporate password vault (KeePass, HashiCorp Vault) indexed by project name, block name, and date. The password is the only thing that opens the block for re-compilation.

11. Verification Checklist After Recovery

When you have rebuilt a protected block from the interface, run the following verification before going to production.

12. Field Notes from Real Recovery Cases

Several patterns recur in protected-block recovery work. Knowing the pattern lets you short-circuit the investigation.

• The "ex-employee" pattern. The original author leaves the company and takes the source. The block is in production. There is no escrow copy. The recovery is to rebuild from the interface and unit-test against recorded behavior. Prevention: use a corporate password vault and a source control system that survives personnel changes.
• The "lost archive" pattern. The source is in an archive on a tape that has been recycled. The compiled block is still in the running CPU. The recovery is to extract the block from the CPU's online program (TIA Portal: Upload from device) and rebuild the source from the interface. Prevention: separate the source archive from the deployment archive.
• The "wrong password" pattern. The author set a password they cannot remember. There is no recovery path in STEP 7 V5.x or TIA Portal. The only option is to use a known-good backup of the project. Prevention: use a corporate password vault.
• The "version mismatch" pattern. The block was protected in TIA Portal V15 and the only available engineering station has TIA Portal V17. The block opens with the original password, but the source representation may differ. Re-compile and re-protect in the new version, then verify the access protection dialog still appears.
• The "library block" pattern. The protected block came from a Siemens or third-party library. The library vendor can re-supply the source under their license. Check the library's documentation, version history, and license terms. Do not decompile a third-party library block; that may violate the license.
• The "master copy" pattern. The block exists as a master copy in a project library or global library. The master copy retains its source. Recover the source from the master copy and recompile into the program.

13. Troubleshooting Matrix

The matrix below summarizes common symptoms, their root causes, and the documented Siemens recovery path.

14. Frequently Asked Questions