Removing KNOW_HOW_PROTECT Block Protection in TIA Portal

Problem Overview: Unlocking a KNOW_HOW_PROTECT Block Without Source Files

A common service call in the field is an integrator receiving an S7-1200 or S7-1500 program from an OEM that contains blocks protected with KNOW_HOW_PROTECT. The integrator opens the project in TIA Portal, navigates to the source folders, performs a full-text search for the string know-how protection, finds nothing, and concludes the keyword is missing. In reality, the keyword only exists in the original text source file (SCL or STL). The block delivered to the integrator is the compiled object, and the compiler strips the KNOW_HOW_PROTECT keyword from the compiled code while keeping only the protection behavior.

This article documents the correct procedure for removing know-how protection in TIA Portal V20, the reason the keyword cannot be located in compiled blocks, the differences between protection types, and the legal path forward when no source file is available. The official Siemens procedure is published in the Removing Block Know-How Protection documentation entry.

Why the KNOW_HOW_PROTECT Keyword Is Not Visible in the Source View

Two distinct artifacts exist for any user block in a TIA Portal project, and the protection keyword lives in only one of them:

When a programmer authors a block, the workflow is:

1. Create or open the text source in External Sources.
2. Insert the KNOW_HOW_PROTECT keyword in SCL or the // KNOW_HOW_PROTECT pragma in STL.
3. Right-click the source and choose Compile to generate the compiled block in Program Blocks.
4. Distribute the compiled block (or the entire project archive) to the integrator.

Step 4 is where the trap lies. The integrator receives the compiled block but not the original text source. A search of the project for the literal string know-how protection in External Sources yields nothing because the source file is missing, not because the keyword was renamed.

Block Protection Types in TIA Portal

Siemens provides three distinct protection mechanisms on blocks. Operators often conflate them; the removal procedure differs.

Know-how protection is the only one of the three that genuinely hides the code; the others can be unlocked by anyone with the password. When a source file is supplied but is read-protected by password, opening the block and clearing the Know-how protection checkbox in Edit > Know-how protection is sufficient.

Diagnostic Steps: Confirming That a Block Is Know-How Protected

Before attempting removal, verify the actual protection state of the block in the project. In TIA Portal V20:

1. Open the project and expand Program Blocks in the project tree.
2. Select the suspect FB, FC, DB, or OB.
3. Open Properties > Protection.
4. Read the Know-how protection checkbox state. If checked, the block is read-protected and the interface/code cannot be viewed.

A second visual indicator is the lock icon overlaid on the block icon in the project tree. In the online view of a connected CPU, the same icon appears next to the block in the online block list.

Prerequisites for Legal Removal

To remove know-how protection legally and without data loss, the following must be available:

• The original SCL or STL text source file with the KNOW_HOW_PROTECT keyword in place. The keyword line must be removed before recompilation.
• OR an unprotected version of the block provided directly by the original author or OEM.
• A TIA Portal installation matching or newer than the version used to compile the original block (for example, TIA Portal V20 can read sources created in V18 onward).
• Write access to the TIA Portal project and the local file system where the project is stored.

If none of these are available, no legal path exists within Siemens tooling to recover the protected code. The recommended action is to contact the OEM and request a new project archive with know-how protection removed, or to recreate the block from functional specification and I/O documentation.

Step-by-Step Removal Procedure in TIA Portal V20

The official procedure documented by Siemens is as follows. Refer to the TIA Portal V20 - Removing Block Know-How Protection page for the source-of-truth reference.

Step 1: Place the Source File in External Sources

If the source file was supplied by the OEM:

1. Open the TIA Portal project.
2. Expand the device folder for the S7-1200 or S7-1500 CPU.
3. Right-click External Sources and choose Add new external source.
4. Import the supplied .scl or .stl file.

If the source is missing entirely, do not proceed with the unprotect procedure. Instead, escalate to the OEM or rights holder to obtain an unprotected source.

Step 2: Generate a Block From the Source (or Open and Edit)

1. Double-click the imported source to open it in the SCL or STL editor.
2. Verify the first lines of the file contain a line equivalent to {SCL_SetBlockAttributes 'KNOW_HOW_PROTECT' := '1'} in SCL, or the pragma // KNOW_HOW_PROTECT in STL.
3. Delete the KNOW_HOW_PROTECT line/pragma entirely. Do not comment it out; the keyword is processed at compile time and a commented line will still be ignored, but the safest and most portable change is full removal.

Step 3: Recompile the Source

1. Right-click the modified source file in External Sources.
2. Choose Compile > Software (All) to regenerate the compiled block. The destination folder is Program Blocks.
3. Confirm that the generated block overwrites the protected version. A prompt appears asking whether to overwrite the existing block.

Step 4: Verify the Protection State

1. Right-click the new block in Program Blocks.
2. Open Properties > Protection.
3. Confirm that Know-how protection is unchecked.
4. Open the block body and confirm that the interface and code are now visible.

Alternative Path: Removing Protection Through the Edit Menu

If the source is already attached to the block (for example, an SCL block generated directly in TIA Portal rather than from an external source), the menu-driven shortcut applies. From the Removing Block Know-How Protection reference:

1. Select one or more blocks in the project tree.
2. Open the Edit menu.
3. Choose the Know-how protection command. The command toggles the state of all selected blocks.

If the block was opened with a read/write password, the password prompt appears first. Enter the password, then the menu command clears the protection attribute. If the password is unknown, this path is closed; the user must still obtain an unprotected source from the author.

Classic STEP 7 V5.x Procedure for S7-300/S7-400

The same logic applies to S7-300 and S7-400 systems programmed in STEP 7 V5.x. The source file lives in the S7 Program > Sources folder. The keyword in the AWL source is:

// KNOW_HOW_PROTECT
FUNCTION FC 1 : INT
// ...body...

To remove protection:

1. Open the source in the LAD/FBD/STL editor.
2. Delete the // KNOW_HOW_PROTECT line.
3. Save and compile via File > Compile.

The compiled block in the offline block container is regenerated without the protection attribute and is downloaded to the CPU on the next download.

When Source Files Are Unavailable: The Real Resolution Path

The diagnostic question is whether the integrator can locate the KNOW_HOW_PROTECT string in the project. If the project contains only compiled blocks and no text source under External Sources (TIA Portal) or Sources (STEP 7 V5.x), the compiled binary is all that exists. Removing protection is then impossible without cooperation from the original author. The recommended communication with the OEM is:

1. Request a new project archive (.zap20 for TIA Portal V20, .s7p/.zip for STEP 7 V5.x) with know-how protection removed from the affected blocks.
2. Specify the block names and block numbers so the OEM can locate them in their source control.
3. Confirm that the archive is delivered with the original text sources, not only compiled blocks.

If the OEM is unreachable or unwilling, the only remaining option is to rewrite the block. Functional specifications, I/O lists, and the call hierarchy visible from unprotected blocks typically provide enough information to rebuild the protected routine. Allocate engineering time for this contingency in any service contract.

Verification and Functional Checks

After recompilation, perform the following checks before downloading to the live CPU:

1. Static review: Open the regenerated block and confirm the interface (input, output, in/out, static, temp) is intact and matches the version that the rest of the program expects.
2. Cross-reference check: Use Project tree > right-click CPU > Cross-references to confirm that no caller block is now broken by the recompilation.
3. Compile clean compile: Compile the entire program (Compile > Software (All)) and verify zero warnings and zero errors. Any signature mismatch with the rest of the program will surface here.
4. Online download to test CPU: Download to a test or backup CPU and exercise the function. Know-how protection does not change runtime behavior; the unprotected block is byte-equivalent to the protected one. Only the visibility at engineering time changes.
5. Production download: Only after successful test on the bench, download to the operational CPU.

Project Re-integration and Block Number Conflicts

A common follow-on issue is that the recompiled source has the same block number as the existing protected block. TIA Portal handles this by asking whether to overwrite. Accept the overwrite, then perform a full project compile to update any block call dependencies. If the recompiled source has a different block number from what the rest of the program references, the program will fault with an Unknown block error. In that case, do not overwrite; instead, regenerate the block under the correct number or update the caller block to call the new number.

Troubleshooting Matrix

Preventive Controls for Multi-Party Projects

To avoid this deadlock on future projects, apply the following controls:

• Specify in the contract that the OEM delivers a TIA Portal project archive plus a separate Sources folder containing all .scl and .stl text files. Both must be covered by the same maintenance window.
• Maintain a vendor-controlled Git or SVN repository of text sources, with the OEM committing each release. Use this repository as the engineering baseline, not the compiled archive.
• Document all block numbers, names, and protection state in the project Functional Design Specification. This gives service engineers a map of what is and is not editable.
• Reserve know-how protection for blocks containing genuinely proprietary algorithms. Use read/write passwords for routine commissioning logic; know-how protection on every block makes service work impossible.

Notes on Compiler Versions and Forward Compatibility

Text sources compiled in older TIA Portal versions (V13 through V17) are compatible with V18 and later for purposes of regeneration. The block number, interface signature, and code body are preserved across compiler upgrades. If the project was originally compiled in V20 and the integrator's installation is V17 or earlier, the source cannot be recompiled because the block container format is newer than the editor supports. The resolution is to install TIA Portal V20 or later, or to ask the OEM to provide a project archive in the older version.

Safety-Critical Considerations

Know-how protection is sometimes applied to safety blocks (F-FB, F-FC, F-DB) generated by the SIMATIC Safety package. The Safety Integrated lifecycle requires that the F-block signatures match between the offline project and the online CPU. Removing protection from a safety block is allowed only if the integrator has access to the safety source and is authorized to modify safety logic. Any modification requires a fresh safety acceptance test, documented in the safety logbook per IEC 61508 and IEC 62061 workflows. Do not modify safety blocks without involving the safety engineer of record.