Moving Siemens S7 F-Runtime Groups Shutdown Risks & Best

Problem Overview

During a brownfield commissioning, an engineer running a SIMATIC S7-400H (CPU 417-4H) Fail-Safe System on PCS 7 V7.0 SP1, S7 F Systems V6.0, and the Failsafe Blocks library V1.2 SP4 must move an F-block's F-runtime group from OB35 position 4/81 to OB35 position 9/11 to close a punch item. The F-program is live, the safety signature is in service, and the engineer needs to know whether this move forces a process shutdown, whether it changes the safety signature, and whether STEP 7 will re-sort the F-runtime group back to its original position after a compile and download. The S7 F Systems programming and operating manual (A5E00085588-05, step7_s7_f_fh_systems_programming_operating_manual_en-US.pdf) explicitly forbids shifting auto-generated F-runtime groups, while Siemens Knowledge Base article 30595708 documents the practical consequences: the safety signature changes, the safety mode must be deactivated to download, and a recompile can reorder F-runtime groups. This article consolidates those rules into a field-usable procedure, a risk matrix, and a verification checklist for any engineer facing the same structural change.

System Context: S7-400H, PCS 7 V7.0 SP1, and S7 F Systems V6.0

The reference platform is the SIMATIC S7-400H with a CPU 417-4H programmed in STEP 7 V5.5 inside PCS 7 V7.0 SP1. The fail-safe layer is the S7 F Systems V6.0 optional package, and the safety function blocks come from the Failsafe Blocks library V1.2 SP4 (commonly referred to as F-lib V1_2). The H-CPU is configured in redundant mode; both subsystems execute the F-program in parallel and cross-check the F-signature on every cycle. The F-runtime groups are dispatched from the cyclic interrupt OB35. Within OB35, each F-runtime group is identified by:

• Phase offset (in milliseconds, the call time relative to OB35 start)
• Run-sequence number (the order in which the F-RTG is called inside OB35)
• F-cycle time (the OB35 interrupt period, typically 100 ms on PCS 7, configurable in HW Config)
• F-monitoring time (the maximum allowed execution time of the F-RTG before the F-CPU passivates)
• F-RTG information DB number (the data block that exposes runtime diagnostics)

The two values reported in the punch item - 4/81 and 9/11 - correspond to two distinct F-runtime group positions inside the same OB35 image. The exact notation depends on the PCS 7 view used (chart vs. table), but the requested change is to move one F-block from one F-runtime group slot to another F-runtime group slot inside OB35, not to a different OB. The two slots differ in phase offset and run-sequence number; both belong to the same OB35 priority class.

F-Runtime Group Architecture and Internal Block Set

Each F-runtime group is a closed execution unit with its own block container generated by the S7 F Systems compiler. The container always contains the following blocks:

The F-PSG_M block is generated automatically by S7 F Systems; the S7 F Systems manual forbids editing the body of F-PSG_M or moving F-PSG_M instances outside the rules in the safety program editor. The F-RTG information DB exposes operational data such as the current F-signature, the passivation count, the F-cycle time, and the F-monitoring-time error flag. According to the TIA Portal SIMATIC Safety Configuring and Programming manual, the F-runtime group information DB is created automatically and provides runtime information about the F-runtime group, including signature, cycle, and passivation state (see SIMATIC Safety - Fail-Safe Blocks). The same architecture applies to classic STEP 7 V5.5 + S7 F Systems V6.0 installations; only the editor surface differs.

The safety signature itself is computed as a CRC over the compiled F-program of the F-runtime group, the F-I/O configuration referenced by that group, the F-monitoring time, and the F-CPU password. The signature is displayed as a hex string (typically 8 hex characters for the CRC plus a 4-character checksum of the F-signature envelope) and is stored both in the CPU and in the offline project. Any change to the inputs of that CRC changes the signature and forces operator re-acceptance.

Siemens Rules for F-Runtime Groups (A5E00085588-05)

The S7 F Systems programming and operating manual (A5E00085588-05) lists the following non-negotiable rules, all of which apply to a runtime-group move:

1. The automatically generated F-Runtime groups must not be shifted. Changes must not be made within this F-Runtime group, either.
2. Only the F-runtime group sequence in OB35 (the order in which F-runtime groups are called) and the F-cycle time / F-monitoring time may be changed via the safety program editor.
3. The channels (channel values and value status) of an F-I/O can only be accessed from a single F-runtime group. Splitting an F-I/O access across two F-runtime groups is a violation.
4. If F-runtime groups are created or moved directly, they must always lie between the first and the last F-runtime group of an F-disabling group.
5. The safety signature is recalculated whenever the structure of the F-program changes, including the assignment of F-blocks to F-runtime groups.

These rules are documented in the SIMATIC Safety - Rules for F-Runtime Groups of the Safety Program topic in the TIA Portal V20 documentation set. Although the on-line platform is TIA Portal V20, the same rules originate in the S7 F Systems V6.0 manual and apply unchanged to classic STEP 7 V5.5 + S7 F Systems V6.0 installations such as the 417-4H reference project.

Impact of Moving F-Runtime Groups: Signature, Shutdown, Compile

Three effects always follow a structural change to the F-program such as moving an F-block between F-runtime groups. The engineer must understand all three before approving the change in a live process.

Effect 1: Safety signature changes

S7 F Systems computes the safety signature as a CRC over the compiled code of the F-runtime group, the F-I/O configuration, the F-monitoring time, and the F-CPU password. Moving an F-block changes the compiled code, so the signature changes. The new signature must be recorded in the safety logbook, compared against the operator-side acceptance value, and the operator must acknowledge the change before safety mode is reactivated. If the operator does not re-accept, the F-CPU remains in passivation.

Effect 2: Safety mode is deactivated on download

STEP 7 refuses to download a modified F-program while safety mode is active. The operator (or the safety engineer) must deactivate safety mode in the F-CPU, perform the download, and then reactivate safety mode. During the deactivation window, the F-I/O is in passivation and the safety function is held in its safe state (typically de-energize-to-trip). For most process plants this is the equivalent of a controlled process shutdown of the affected safety loop. The deactivation also wipes the F-signature check temporarily; on reactivation the F-CPU performs a full self-test and signature check before depassivating any F-I/O.

Effect 3: Compile may re-sort F-runtime groups

Per Siemens KB 30595708, the redistribution of F-runtime groups caused by placing, deleting, or moving the F_PSG_M block cannot be avoided. In practice this means that after a compile the moved F-block may be placed into a different F-runtime group than the one selected manually. The engineer must verify the actual F-runtime group assignment in the safety program editor after every compile, not trust the placement made in the previous download.

Siemens Knowledge Base 30595708: Confirmed Behavior

Siemens KB 30595708 ("What should you watch out for when creating or moving F-runtime groups and using the F-library Failsafe Blocks V1_2 or Failsafe Blocks V1_1?") is the definitive reference for the topic. The article confirms the following for installations using F-lib V1_1 or V1_2 on top of S7 F Systems V6.0:

• You cannot avoid the redistribution behavior if you place, delete, or move the F_PSG_M block; the module-side grouping can change on a subsequent compile.
• If you directly edit or create F-runtime groups, they must always lie between the first and the last F-runtime group of an F-disabling group.
• A change in the F-runtime group structure invalidates the F-signature.
• The F-program editor will display the new F-RTG information DB block number; the operator must update the safety logbook with the new block numbers and the new signature.
• The KB is the canonical source for any field engineer working with F-lib V1.2 SP4 on an S7-400H, so its conclusions are directly transferable to the 417-4H project.

Step-by-Step Procedure (When Movement is Unavoidable)

If the F-runtime group move cannot wait for a planned turnaround, follow this sequence. The procedure assumes the S7-400H is the active F-CPU, the F-program is in safety mode, and operator authorization to deactivate safety mode has been obtained in writing.

1. Capture the baseline. In STEP 7, open the F-runtime group editor, right-click the source F-runtime group, choose "Print" or export the report, and record the F-signature, the F-RTG information DB number, and the F-block list. Save the file in the project archive folder with a timestamp.
2. Compile and verify on the offline simulator first. Open the S7-PLCSIM instance, load the modified S7 program, and check that the F-signature changes as expected and that the F-runtime group sequence is preserved after compile. Note the new F-signature and the new F-RTG DB numbers. The simulator reproduces the compile and signature behavior, but it does not reproduce the F-I/O passivation behavior of real PROFIsafe modules.
3. Notify operations and obtain a process permit. Inform the control room that safety mode will be deactivated, that the affected safety loop will passivate, and that the plant must transition to its safe state for the affected equipment. Lock out the affected equipment per site LOTO procedure if the F-I/O drives final elements that cannot tolerate a brief de-energize.
4. Deactivate safety mode in the F-CPU. In STEP 7, target the active F-CPU, choose Safety → Deactivate safety mode, and enter the F-CPU password. The CPU drops safety mode and the F-I/O passivates. Both H-subsystems must be in this state for the download to proceed.
5. Download the modified F-program. Use Target system → Download → Safety program only (or All if the standard program is also changed). STEP 7 will prompt for the new F-signature; record the value before confirming.
6. Inspect the F-runtime group editor after download. Open the safety program editor and verify that the F-block is now in the target F-runtime group. If S7 F Systems re-sorted the F-runtime group, the block may have landed in a third F-runtime group; in that case, repeat the move and download until the placement is correct.
7. Record the new F-signature. Note the new F-signature in the safety logbook, the F-CPU password envelope, and the operator acceptance record. Also record the new F-RTG information DB numbers and the new phase offset.
8. Reactivate safety mode. In STEP 7, choose Safety → Activate safety mode, enter the F-CPU password, and confirm the F-signature. The CPU performs a self-test, depassivates the F-I/O, and resumes the safety function.
9. Verify passivation/depassivation. In the F-CPU diagnostic buffer, confirm that the F-I/O entered and left the passivation state cleanly with no CRC, watchdog, or signature faults logged since the download.
10. Return the process to operation. With operator approval, bring the affected equipment back to its operating state. Update the cause-and-effect matrix, the safety function specification, and any PCS 7 OS faceplate references to the F-runtime group.

OB35 Phase Reassignment: Mechanics in PCS 7 V7.0

OB35 in PCS 7 is the default cyclic interrupt for the F-program. On the S7-400H, OB35 is typically configured with a 100 ms cycle in HW Config. The phase offset is the delay (in ms) between the OB35 start event and the actual call of the F-runtime group; the F-cycle time is the OB35 period. To move an F-runtime group from position 4/81 to position 9/11, the engineer must:

1. Open the S7 F Systems safety program editor in STEP 7.
2. Select the source F-runtime group, note its F-PSG_M instance, the F-block list, and the F-RTG information DB number.
3. Select the target F-runtime group (or create a new F-runtime group at the target phase using the safety program editor) and assign the F-block to the new F-RTG.
4. Compile the safety program. The compiler will generate new F-PSG_M instances and a new F-RTG information DB; the previous F-RTG information DB becomes obsolete.
5. Re-check the runtime group order in the OB35 image (HW Config → CPU properties → Cyclic Interrupts tab) to confirm the new phase offset and run-sequence number.

If the target F-runtime group does not yet exist, the engineer must create it with the safety program editor. Per Siemens KB 30595708, the new F-runtime group must lie between the first and the last F-runtime group of any F-disabling group. An F-disabling group is a logical grouping used to passivate F-I/O together; F-runtime groups inside an F-disabling group share a common passivation trigger, and the F-CPU passivates all of them when any one of them reports a fault.

Verification Checklist After Download

Best Practices and Field-Engineer Recommendations

1. Treat F-runtime group moves as a turnaround activity. The cleanest answer to the question "will moving an F-runtime group require a shutdown?" is yes, in the sense that the affected safety loop will passivate while safety mode is deactivated. Schedule the move in a planned outage, not in a live process window.
2. Never edit auto-generated F-PSG_M. The body of F-PSG_M is generated by S7 F Systems. Manually changing it breaks the safety signature in a way that STEP 7 cannot recompile cleanly and that safety mode may refuse to accept.
3. Verify after every compile. Do not trust a single compile-and-download cycle. Recompile the safety program, compare the F-runtime group order in the editor with the intended layout, and only then download. The redistribution behavior documented in KB 30595708 means the position can change silently between compiles.
4. Keep an archive of F-signatures. Store every F-signature with the date, the engineering change order, and the F-runtime group block numbers. The TIA Portal SIMATIC Safety manual recommends recording signatures in the F-runtime group information DB documentation (see Fail-Safe Blocks); the same rule applies to classic STEP 7 and S7 F Systems V6.0.
5. Bound the F-I/O access to one F-runtime group. If the F-block move is motivated by trying to share an F-I/O between two safety functions, do not move the block. Either keep both functions in one F-runtime group or duplicate the F-I/O into a second PROFIsafe module.
6. Document the OB35 phase. The OB35 phase offset and run-sequence number are part of the safety program documentation. Update the cause-and-effect matrix, the safety function specification, and the F-CPU password envelope to reflect the new phase. This satisfies the IEC 61508 / IEC 61511 requirement that every change to a safety function be documented.
7. Keep the simulator and the real PLC in lockstep. The S7-PLCSIM simulator reproduces the compile and signature calculation, so it is the right tool to validate the F-runtime group layout before exposing the live process. However, simulator passivation tests are not a substitute for a controlled real-CPU test with the affected equipment in a safe state.
8. When in doubt, close the punch point another way. If the move is a "nice to have" rather than a hard functional requirement, prefer a procedural change (operator action, additional hard-wired interlock) that does not require a structural change to the F-program. The structural change adds a new F-signature to the safety logbook for the rest of the plant life and complicates future audits.

Troubleshooting Matrix