Upgrading TIA Portal V13 to Support S7-1500 Safety System V2.1

Overview: The TIA Portal V13 / Safety System V2.1 Compatibility Gap

Engineers porting legacy F-programs from SIMATIC S7-300F to SIMATIC S7-1500F frequently hit a single wall: the F-IO data blocks that exposed point-specific quality bits (QBAD / value status) on every channel of an F-module under STEP 7 Safety V13 SP1 never materialized in the S7-1500 world until Siemens shipped Safety System V2.1. The user's 2015-era library, anchored on V13, simply has no place for those bits because the F-runtime generated in V13 only emits the legacy aggregate QBAD on the F-IO DB header.

Safety System V2.1 is a runtime upgrade, but it is gated on three things simultaneously:

1. The TIA Portal engineering version used to compile the F-program (must support Safety System V2.1).
2. The SIMATIC F-CPU firmware (S7-1500F / ET 200SPF CPU must carry firmware that ships the V2.1 signature).
3. The F-I/O module firmware in each PROFIsafe slot (point-specific QBAD is generated per-channel only when both ends of the PROFIsafe link support channel-level diagnostics).

The hard answer: TIA Portal V13 cannot host Safety System V2.1. The minimum engineering shell that recognizes Safety System V2.1 is TIA Portal V14 SP1 with the matching STEP 7 Safety Advanced option package, and the realistically supportable shell for production work today is V15.1 or later. V13 has no update path to V2.1 — it is a one-way upgrade of the engineering tool itself.

Why QBAD Matters: S7-300 vs S7-1500 Fail-Safe I/O Diagnostics

QBAD (Quality BAD) is the boolean the F-CPU sets when it cannot guarantee that the process value currently sitting in an F-input DB is trustworthy. On S7-300F with classic distributed F-modules (ET 200S, ET 200pro, ET 200eco), STEP 7 Safety generated an F-IO DB per station, and each station DB carried an aggregated QBAD plus per-point value-status flags. The classic 2015-era libraries used those bits directly in the safety logic:

• iQBAD_START_ADDRESS — first word of the station aggregate.
• iValue_START[i] — process value word per channel.
• iValue_STATUS[i] — per-channel bit-validity flag (sometimes labeled QBAD_I[i] in user code).

When the S7-1500F family debuted, the initial F-runtime (Safety System V1.x) emitted only the aggregate F-IO DB QBAD. Channel granularity was buried in the diagnostics buffer, not surfaced as DB tags. That forced 300F-to-1500F ports to either:

• Re-write the safety logic to use the aggregate bit + manual channel tracking via RDREC / RD_SI on each F-module, or
• Wait for Safety System V2.1, which restores per-channel value-status bits in the F-IO DB so legacy code drops in unchanged.

Restoring per-channel QBAD is not a cosmetic change — it is the difference between an F-program that can detect a single welded contact on a 6-channel F-DI module and an F-program that can only detect that something on the station is bad.

Compatibility Matrix: TIA Portal, Safety System, and S7-1500 Firmware

The following table consolidates what Siemens has shipped and which combinations will compile, download, and run a Safety System V2.1 F-program on an S7-1500F CPU. Confirm against the live SIMATIC Safety Integrated entry and the official migration guide before locking in a target version.

Two cells matter for this specific question:

1. TIA Portal V13 generates F-runtime Safety System V1.x. There is no installed option package, hotfix, or HSP that lifts it to V2.1. Confirmed by Siemens support note SN92961C and the V13-to-current migration guide in the TIA Portal Help.
2. V14 SP1 is the earliest tool that emits Safety System V2.0, but V2.0 still does not expose point-specific QBAD on every F-module. You want V15.1 or later for V2.1.

Hardware-Specific QBAD Availability in Safety System V2.1

Even when the engineering shell and CPU firmware are correct, per-channel QBAD is only emitted by F-I/O modules whose firmware supports channel-level value status. The aggregate-only modules were the trap behind the source-thread statement "Safety System 2.1 is also hardware specific."

For the engineer's mental model: if the F-module can expose a non-zero ChannelFault record under RDREC index 0x0010, Safety System V2.1 will fold that into the F-IO DB value-status array. If the module returns a station-level fault only, you still get an aggregate QBAD and no per-channel array.

Prerequisites: Licensing, Software, and Hardware Setup

Before starting the migration, assemble the following. Anything missing here is a guaranteed trip to the field for a missing DLL.

• TIA Portal V15.1 or later, installed with the STEP 7 Safety Advanced option. V18 is the practical target in 2025 because of its wider firmware envelope and downgrade rights.
• F-CPU firmware at or above the value listed in the matrix. Current production target is FW 2.9.x for stability; FW 4.x is the long-term maintenance branch on newer 1500/1500T hardware.
• STEP 7 Safety HSP files matching the F-I/O you have in the cabinet. Siemens ships new module firmware and HSPs separately; an HSP upgrade is required to make V2.1 PB-features appear in the device catalog.
• Siemens Automation License Manager (ALM) with the upgraded license key migrated to the new USB dongle or software license.
• Original V13 project archive, password if encrypted, plus the offline safety signature print-out so the post-upgrade F-signature can be compared.
• PG/PC Ethernet with a routable path to the F-CPU (separate service interface on the CPU — do not route through a managed plant switch carrying PROFINET IRT without configuring it).

Step-by-Step Migration from TIA Portal V13 to V14+

Perform the migration on an engineering PG with the original V13 archive closed and a full project backup on disk before any click.

1. Archive the V13 source. Use Project > Archive and store the .zap13 on read-only media. Verify the archive extracts cleanly to a fresh directory.
2. Install the target TIA Portal (V15.1 minimum, V18 preferred) with STEP 7 Safety Advanced. Install matching HSPs for every F-I/O module in the bill of materials.
3. Open the archive in the new shell. TIA Portal prompts for an automatic upgrade — accept. The tool rewrites device versions, GSD/GSDML references, and the F-runtime group header. Watch for unresolved references in the Project tree > Common data > Logs window.
4. Re-assign device firmware versions. In each F-CPU and F-I/O properties, set the firmware to a version that supports Safety System V2.1 (CPU FW ≥ 2.5; module FW per the table above). Compile.
5. Verify the F-runtime group. Open the F-runtime group editor. The signature header should now read Safety System Version 2.1.x. If it still shows V1.3, an HSP is missing — the F-CPU did not get new PB-features.
6. Inspect the F-IO DB. Each station DB now contains an array of value-status bits matching the channel count. For example, an 8-channel F-DI station shows: VALUE_STATUS[1..8] : BOOL; QBAD : BOOL; // aggregate, retained ACK_NEC : BOOL; // operator must acknowledge the QBAD
7. Recompile the F-program. Use Compile > Software (rebuild all blocks). Resolve any warnings about renamed system FB/FC blocks (e.g., F-I/O-DB instance DB names are normalized in V2.x).
8. Download and assign F-signature. Connect to the CPU, perform an Online & Diagnostics > Safety > Assign F-signature. Compare the new CRC against the pre-upgrade print-out. Save the post-upgrade signature PDF to the safety file.
9. Re-run the safety acceptance test. Mandatory: every F-channel, every category stop, every acknowledge path must be physically actuated and logged. The F-signature alone is not proof of functional safety — the acceptance test is.

Firmware Strategy: Stabilizing the S7-1500 F-CPU

Two firmware axes intersect on the F-CPU:

• CPU firmware (CPU-FW) — controls F-runtime behavior, OPC UA server, motion, and web API.
• Display / front-panel firmware — not safety-relevant, but mismatched display FW causes nuisance diagnostics.

For the engineer porting a 2015 program, the practical guidance is:

1. Avoid S7-1500F CPU firmware below 2.8 on production machines. The 2.5/2.6 branches had well-documented F-runtime edge cases that Siemens formally retired in 2.8.
2. Do not run an F-CPU on the very newest firmware day-one of release. Wait one HSP cycle (typically 3–6 months) so Siemens can ship the post-release bug-fix HSP.
3. If the F-CPU is on a V2.x branch and the plant tolerates a brief stop, jump straight to the latest V2.9.x maintenance release — it preserves V2.1 Safety System behavior and is the longest-supported legacy branch.
4. For greenfield, jump to FW 4.x on a current CPU (e.g., CPU 1515F-2 PN, 6ES7515-2AM02-0AB0) with Safety System V2.5.

Verifying Point-Specific QBAD in the F-IO DB

Once the upgraded program is running, prove the per-channel QBAD bits are alive. The fastest verification cycle is:

1. Force the F-CPU to RUN with safety mode active. Confirm green SAFETY LED and no SF (group fault).
2. Open Watch & Force tables, insert the F-IO DB tags: F_IO_DB_1.QUA_CHAN[1] (or VALUE_STATUS[1] depending on F-runtime naming) F_IO_DB_1.QUA_CHAN[2] ...
3. Disconnect a single channel wire on F-DI channel 3. The corresponding value-status bit must transition to 1 within one PROFIsafe cycle (typically 8–32 ms). The aggregate QBAD bit must also transition; the per-channel bit must remain set even if the aggregate clears after the operator ACK.
4. Reconnect, ACK the QBAD on the HMI, and confirm the channel bit clears back to 0 on the next safety cycle.
5. Repeat for every channel and every F-station. Document each in the safety acceptance test report.

If a channel does not transition its value-status bit when its wire is pulled, two things are wrong simultaneously: either the module firmware is too old to expose channel-level diagnostics, or the F-runtime group is still on Safety System V2.0 (rare on V15.1+, but possible if the project upgrade step was skipped). Re-check the F-runtime group header.

Commissioning and Field-Proven Caveats

The following are the highest-impact traps engineers hit when promoting a V13 program onto a 1500F with Safety System V2.1. Treat this list as a pre-commissioning checklist.

• F-runtime group cycle time: The default cycle budget grows when per-channel QBAD is enabled. If your group ran at 10 ms in V13, expect 15–20 ms in V2.1 on the same hardware. Recalculate the worst-case safety response time. The formula is t_response = t_input + t_F_runtime + t_output; if t_response now exceeds the application limit, lower the F-runtime OB priority or split the group.
• PROFIsafe addresses (F-source / F-destination): The V13 project stores these per slot. After upgrade, TIA Portal may renumber if it finds a collision. Print the PROFIsafe addresses table from both V13 and V15.1+ and diff.
• Operator ACK routing: The aggregate QBAD bit historically shared an ACK with the per-channel bits. V2.1 splits them — you must add a per-channel ACK path in the F-program if your HMI masks channels independently.
• Password / know-how protection: V13 used the legacy block-protection algorithm. V18 blocks are protected with the newer SHA-based algorithm. If the source library was know-how protected in V13, you must obtain the source — re-protection in V2.1 cannot reverse-engineer the old F-block internals.
• Library compatibility: The user mentioned "my development library." If the library is itself a TIA Portal global library compiled under V13, it must be re-saved under the target version. Re-saving in a newer shell is supported; opening the same global library in V13 after it has been touched by V18+ corrupts it.
• Display language / comment language: The F-program comments are migrated but project text in languages not shipped with the target TIA Portal will fall back to English. Re-import the language pack before the FAT if the customer's HMI is multi-lingual.

Troubleshooting Matrix

Reference Path for the Original Question

To restate the original question crisply:

"Can I stay on TIA Portal V13 and patch in Safety System V2.1 to get point-specific QBAD bits on the S7-1500F?"

The defensible answer is no. Safety System V2.1 is not a drop-in update for V13. The path forward is:

1. Stay on V13 only if you also stay on the legacy 300F hardware and accept aggregate-only QBAD.
2. If the machine is already on a 1500F, upgrade the engineering tool to at least V15.1 (V18 strongly recommended) and accept the safety re-acceptance test cost.
3. Confirm every F-module's firmware supports channel-level diagnostics before promising the per-channel QBAD behavior to the customer.

The V18 license downgrade path allows the V13 archive to be read for archival reference without forcing the safety team to maintain two parallel engineering shells forever.