Resolving ET200SP F-CPU Upload Failure in TIA Portal V15

Problem Definition: "The selected device Software PLC cannot be uploaded"

When attempting to upload a project from a Siemens ET200SP F-CPU (F-PLC / Fail-safe PLC) into a freshly installed TIA Portal V15 project, the engineering station reports the diagnostic message "The selected device Software PLC cannot be uploaded". Device discovery (Accessible Nodes / Online & Diagnostics) succeeds and the F-CPU is visible on the fieldbus, but the upload operation terminates immediately once the F-CPU is selected. This symptom is not a network fault, a missing GSD, or a password issue — it is a deliberate platform-level restriction of the F-system toolchain that depends on the TIA Portal version and the F-CPU firmware revision.

The error text is generated by the TIA Portal project server when it inspects the F-CPU's Safety Administration Editor metadata and determines that the binary program on the device does not carry the upload-allowance flag. The same dialog returns the same text whether you target a standard IM 155-6 PN HF station head with an F-CPU 1510SP F / F-CPU 1512SP F or an IM 155-6 PN/2 HF with a SIMATIC ET 200SP F-module array.

Root Cause: F-PLC Upload Protection

SIMATIC F-CPUs implement an additional integrity layer over the standard S7 program container. The F-runtime block (F-ShDB, F-shared data block, and the safety program OB blocks — typically OB35 or OB123 cyclic, plus OB82, OB121, OB122 F-fault handlers) are signed with the F-collective signature at compile time and then transferred to the F-CPU with a binding through the Safety Administration Editor. The collective signature is the SHA-256 hash that ties together the safety program, the F-I/O configuration, and the safety-related parameter set.

To prevent unauthorized extraction of the safety program (which on certified machinery is a regulatory issue under IEC 61508 / IEC 61511 / ISO 13849-1), Siemens introduced a binary switch called "Allow upload of the safety program to the PG/PC" (German: Hochladen des Sicherheitsprogramms auf PG/PC zulassen). This switch is only present inside the Safety Administration Editor of TIA Portal V16 and later, with F-CPU firmware V2.8 and later. If the switch is set to disabled before the initial download, the F-CPU stores a flag in its system data that prevents any future upload — including from TIA Portal V15. There is no retroactive toggle on the device side, and the F-CPU's web server exposes no API to clear the flag.

Affected TIA Portal Versions and F-CPU Firmware

The upload-allowance feature was introduced in a specific intersection of TIA Portal version and F-CPU firmware. The table below is the conservative compatibility map derived from the SIMATIC S7-1500 / ET200SP F-CPU release notes.

For reference, the canonical Siemens manuals that describe this behaviour are:

• SIMATIC ET 200SP F-CPU 1510SP F / 1512SP F manual (function manual — safety administration section).
• SIMATIC S7-1500 / ET 200SP F-CPU Programming and Operating Manual.
• TIA Portal V16 release notes / readme — new F-functions.
• F-CPU firmware V2.8 release notes.

Compatibility Matrix: Device Identification

Before assuming the F-CPU is locked, verify the exact hardware article number and firmware. The following items are the production F-CPUs that exhibit the upload restriction when combined with TIA V15:

The current firmware on the device can be read without project upload through Online & Diagnostics → Diagnostics → Module Information → Firmware. Note the FW version string exactly — e.g. V2.8.7 — because TIA Portal V15 cannot read F-CPUs with FW > V2.5 without a HSP (Hardware Support Package).

Diagnostic Procedure for the Upload Failure

Follow the steps below to confirm the root cause and eliminate misdiagnosis.

1. Verify accessible nodes. From TIA Portal V15 select Online → Accessible Devices. The F-CPU must appear with a green icon and a reachable PROFINET name. If red, the failure is network, not upload-protection.
2. Check firmware and HSP. Open Online & Diagnostics on the F-CPU. If the firmware is V2.6 or higher and TIA V15 has no matching HSP installed, the upload will fail with a different error (module does not support online functions) — this is not the F-upload error.
3. Confirm the error text exactly. The "The selected device Software PLC cannot be uploaded" wording is unique to the F-system upload restriction. Standard S7-CPUs would say "Online connection to the device was interrupted" or "Upload not possible because password-protected".
4. Check the project version. Open Project → Properties → Information. If the project was created in V16 or V17, TIA V15 cannot open it for download. A new empty V15 project used as a "upload target" must still match the device description — the F-CPU article number must be in the V15 hardware catalog.
5. Look for the Safety Administration Editor. In the project tree, right-click the F-CPU. If the menu item Safety Administration is missing or greyed out, TIA V15 cannot write the upload-allowance bit, regardless of firmware.

Workaround 1: Request the Original Archive from the OEM

The recommended path is the documented, audited route. Because the OEM holds the master project (and the safety collective signature key), they can:

1. Export the project as a .zap15 / .zap16 / .zap17 TIA Portal archive and send it to the end user.
2. Generate a PDF export of the safety program with the collective signature for traceability.
3. Re-issue the project with the Upload of safety program toggle enabled for future maintenance windows.

This is the path that meets the requirement of regulatory bodies (TÜV, BG, OSHA equivalency) and keeps the safety lifecycle file consistent. Archival of the safety program in version-controlled storage is mandated by most safety standards — it is not optional in a certified line.

Workaround 2: Online Comparison Without Upload

If the OEM only needs verification that the installed program has not been tampered with, an upload is unnecessary. Use the online / offline comparison tool:

1. Open the V15 project with the device configured (even an empty V15 project with the matching F-CPU article number).
2. Select Online → Go Online. All blocks should appear green.
3. Select Online → Compare Offline/Online. The result is a block-by-block equivalence table.
4. Take a screenshot of the Online → Diagnostics → Safety Administration → Collective Signature dialog and the Online → Accessible Nodes view.
5. Send the screenshot set to the OEM. The collective signature alone proves the program matches what was originally downloaded, because the signature is generated from the program and the F-I/O configuration.

Workaround 3: Upgrade TIA Portal and F-CPU Firmware

If the OEM agrees, perform a controlled upgrade so that future maintenance uploads are possible:

1. Update the F-CPU firmware to V2.8 or later using the Siemens firmware update tool. Recommended targets: V2.9.7 (latest V2.9 branch, stable for most legacy F-I/O) or V3.1.x (latest stable for new builds).
2. Install TIA Portal V16 Update 7 or later (V17, V18 also supported). The license key for the F-option must be present — "STEP 7 Safety Advanced" (article 6ES7833-1FC00-0YF5 or later).
3. Re-download the OEM-provided project after opening the Safety Administration Editor and enabling the Upload of the safety program to PG/PC checkbox.
4. Document the change in the safety lifecycle file with date, person, and new collective signature.

Prevention: Activating Upload During Initial Download

The single most useful preventive measure is to enable the upload flag at the first project download and never disable it. The path inside TIA Portal V16 / V17 is:

1. Open the project tree and double-click Safety Administration under the F-CPU.
2. Select the line F-runtime group 1 (or whichever F-runtime group is in use).
3. Tick the checkbox "Allow upload of the safety program to the PG/PC".
4. Compile the project (Project → Compile → Software (rebuild all)).
5. Download the entire station.
6. Confirm the collective signature in Online → Safety Administration → Show collective signature — the signature must remain identical to the pre-upload value if no logic was changed.

This single setting eliminates the upload-failure scenario for the next maintenance window without any security penalty: the safety program is still signed and the collective signature is still verified by the F-CPU at every restart. What changes is that an engineer with the project password can now read the F-blocks back into the engineering station.

Verification Checklist After the Workaround

After applying any of the workarounds above, confirm the resolution with this checklist:

• Accessible nodes: F-CPU reachable with green status, no diagnostics buffer entries SF / BF red.
• Firmware version: matches the planned version (V2.8 or higher if upload is desired).
• Safety Administration Editor: present in the project tree, toggle visible, toggle set to enabled for future maintenance.
• Collective signature: matches the value archived in the safety lifecycle file.
• Online / Offline compare: returns a fully green table, no offline-only blocks.
• Diagnostic buffer: no entries indicating signature mismatch or F-parameter inconsistencies.
• Password set: the F-CPU has a CPU password and the project password for protection of confidential know-how. The upload path respects both passwords.

Related F-System Constraints and Edge Cases

The upload-protection flag is one of several constraints that catch engineers off-guard when working with F-systems. The following cases are commonly encountered alongside the upload error:

• Standard CPU but F-I/O present: A standard CPU 1510SP-1 PN can run an F-program only when the Safety option is licensed. Upload of the F-program is then subject to the same Safety Administration toggle as on a dedicated F-CPU.
• Different TIA version, same machine: A project created in V17 cannot be uploaded into V15. Reverse compatibility (newer to older) is blocked by TIA Portal at project-open time, before the upload is even attempted.
• SIMATIC Memory Card swap: Pulling the card and reading it offline is not supported on F-CPUs. The card content is encrypted with a per-CPU key. Use Online → Backup in TIA Portal to produce a .psb / .par backup instead.
• Reset to factory settings: MRES on an F-CPU clears the user program but does not clear the upload-allowance flag (the flag is a project-level, not device-level, attribute). A factory reset therefore does not enable upload.
• Know-how protection: A separate know-how-protected block does not block upload, only viewing. The F-collective signature remains visible.
• Cross-collective-signature changes: Editing the F-program after a successful upload changes the collective signature. The next upload will then return a different signature — this is correct behaviour and is the integrity proof.

Field-Commissioning Notes

For maintenance engineers working on machines already in production, the following practical sequence is recommended when an upload is needed:

1. Do not attempt MRES or factory reset — this breaks the certified safety lifecycle and may require re-validation by the notified body.
2. Contact the OEM first — they hold the master project and can issue an updated archive with the upload flag enabled.
3. Use the online / offline comparison as an interim integrity check if the OEM is not reachable.
4. Plan an upgrade window — update TIA Portal and F-CPU firmware together, never piecemeal.
5. Update the safety lifecycle file with the new firmware version, the new collective signature, and the person performing the change.
6. Run a proof test of the safety function (typically a manual E-stop activation with observation of the safe output drop-out) before returning the line to production.

FAQ