Modifying F-IO in SIMATIC Safety Programs: TIA Portal Methods

Problem Overview

During commissioning or functional testing of a SIMATIC Safety (F-CPU) program in TIA Portal, engineers routinely encounter the situation in which a fail-safe input or fail-safe output (collectively F-I/O) cannot be modified through a Watch Table (VAT) or via the online Hardware Monitor / Modify dialog. The symptom presents itself in several typical ways:

• The F-I/O address is visible in the project tree and reachable online.
• The "Modify" or "Monitor/Modify" column is enabled in the watch table, and the trigger conditions (rising edge of the control bit, correct operating mode) are satisfied.
• After clicking "Modify now", TIA Portal reports success, but the actual process value visible in the F-I/O diagnostics never changes.
• Even with safety mode deactivated and the F-password entered, the standard online tools still do not propagate a write to the F-I/O image.

Because fail-safe I/O is bound to the PROFIsafe safety protocol and verified through a safety signature, ordinary online modify operations that apply to standard I/O do not propagate to the safety layer. This article documents the architectural root cause, the legitimate engineering paths that exist, and the supported workaround using PLCSIM for office-based functional verification of F-IO logic.

Technical Background: SIMATIC Safety Architecture

SIMATIC Safety is the Siemens fail-safe extension to the S7-1500, ET 200MP, ET 200SP, ET 200pro, and ET 200iSP families. It allows the same controller to execute standard (non-safety) and safety-related logic in a single F-CPU. The safety program runs inside a protected runtime container, isolated from the standard user program, and is identified by a unique F-signature. The container is protected by the F-password and, in the default configuration, by the F-CPU's access level (know-how protection plus write protection).

Fail-safe I/O modules (F-I/O) communicate with the F-CPU using the PROFIsafe protocol over PROFINET or PROFIBUS. Each F-I/O module is parameterized with two distinct parameter sets, as defined in the official TIA Portal Safety documentation:

• F-parameters (F-Parameters): Safety-relevant configuration such as the PROFIsafe destination address, the F-monitoring time, the F-source address, the F-block ID, the F-parameter version, and the SIL/PL category. These parameters are part of the F-signature and cannot be modified at runtime without re-compiling and re-downloading the safety program.
• i-parameters (i-Parameters): Non-safety-relevant configuration such as input filter times, channel-level diagnostics enable, substitute value behavior, and value status mapping. These are downloaded to the module during commissioning and are not part of the F-signature.

For the safety layer to remain valid, the F-CPU must guarantee that any input it accepts from an F-I/O has been integrity-checked, and any output it writes to an F-I/O is verified on the wire. The PROFIsafe layer wraps each telegram with a CRC that is recalculated by the receiver; the F-monitoring time defines the maximum interval between two consecutive valid PROFIsafe telegrams before the F-I/O is passivated. Any external value injection at the I/O level would defeat the safety contract.

Why VAT and Hardware Monitor/Modify Cannot Modify F-IO

The TIA Portal Watch Table (VAT) and the Hardware Monitor/Modify dialog operate on the standard I/O image of the CPU. They write to the process image of standard inputs and outputs (PII / PIQ), which is the same image used by the standard user program OB (typically OB1, OB35, or OB82). Fail-safe I/O is mapped into a separate fail-safe I/O image (F-I/O image) that is only accessed by the safety program OB, and only inside an F-runtime group.

An F-runtime group is a cyclic organizational block (for example, OB35 at 100 ms, or OB123 in newer TIA Portal versions for the S7-1500) that contains the F-blocks. The F-runtime group compiler generates a dedicated F-I/O DB for every F-I/O module, and the F-runtime group dispatcher reads the F-I/O image and writes it to the F-I/O DB at the beginning of each cycle, then writes the F-I/O DB back to the F-I/O image at the end of the cycle.

As a consequence, the standard VAT cannot address the F-I/O image at all. Even if the symbolic name of a fail-safe tag is entered into a watch table, the underlying physical address points to the F-I/O area, and the write request is rejected by the F-CPU's safety layer. This is by design and is documented in the Addressing F-I/O section of the SIMATIC Safety manual.

The "deactivate safety mode" option in the F-CPU only releases the safety password for online changes to the safety program itself (LAD, FBD, or STL blocks belonging to the F-runtime group). It does not grant a write path to the F-I/O process image. The only legitimate way to influence a fail-safe input or output value during engineering is to modify the source program code, recompile the safety program, regenerate the F-signature, and download the new signature-protected safety program to the F-CPU.

Root Cause Analysis Matrix

The F-Signature and F-Password

Every F-runtime group has two cryptographic identifiers that protect it from unauthorized modification:

• F-signature: A 32-bit hash computed from the safety program code, the F-I/O configuration, and the F-runtime group parameters. The F-signature is computed by TIA Portal at compile time and is stored both in the project and in the online F-CPU. If the two signatures differ, the safety program will not start.
• F-password: A user-defined password that must be entered in the safety program editor to download a new safety program, change the F-signature, or change the F-CPU's safety mode. The default is blank, which is acceptable for development but must be set before commissioning.

When the F-CPU is in RUN and the safety program is executing, any change to the F-I/O configuration, the F-runtime group parameters, or the safety program code itself requires a download. The download triggers an F-password prompt, a STOP-to-RUN transition (if the F-CPU is configured to stop on safety download), and a new F-signature verification on the next start-up.

PROFIsafe Wire-Level Integrity

PROFIsafe operates as a black-channel safety protocol. The F-CPU appends a 3-byte CRC (or 4-byte CRC in PROFIsafe V2) to each cyclic data telegram. The CRC covers the payload data, the PROFIsafe sequence counter, and the PROFIsafe address. The F-I/O device recalculates the CRC on every telegram; if the calculated CRC does not match the transmitted CRC, the telegram is discarded and the F-I/O is passivated.

Because the CRC is computed by the F-CPU based on the actual F-runtime group data, no external tool can insert a value into the F-I/O image that would produce a valid CRC. The only way to influence the value is to be the F-runtime group itself, which means modifying the safety program and triggering a new download. This is the technical reason why VAT-based modification is rejected even when the F-password is known.

Passivation and Re-Integration

Passivation is the safety state in which an F-I/O channel is forced to a safe substitute value (typically 0) regardless of the value requested by the F-runtime group. Passivation is triggered by:

• PROFIsafe communication errors (CRC mismatch, sequence counter error, watchdog timeout)
• Channel-level faults (sensor short-circuit, sensor wire break, discrepancy error)
• Module-level faults (power supply failure, internal diagnostics failure)
• F-runtime group entering the global safe state (e.g., a fail-safe function block detects an unsafe condition)

Re-integration is the act of clearing the passivation bit and resuming normal operation. Re-integration can be performed by the safety program (using the ACK_OP or ACK_GL blocks), by an operator action on an HMI, or by an automatic re-integration policy configured in the F-I/O parameters. The choice between manual and automatic re-integration is a safety design decision: SIL 3 and PL e applications typically require manual re-integration, while lower SIL/PL applications may accept automatic re-integration.

Supported Engineering Path: Modify the F-Program

Within the safety program, the values presented to the safety logic are the F-I/O tags generated automatically by the F-runtime group compiler. The legitimate way to influence a fail-safe input value during engineering is to modify the source program code, recompile the safety program, regenerate the F-signature, and download the new signature-protected safety program to the F-CPU. The standard sequence in TIA Portal is:

1. Open the F-runtime group block (for example, FB_SafetyEstop) in the safety program editor.
2. Select the failing logic and apply the engineering change. The change can be a constant replacement, a new interlock, a logic inversion, or a new sub-function block.
3. Compile the safety program. TIA Portal will prompt for confirmation if the change affects the F-signature.
4. Authenticate with the F-password when prompted.
5. Download the safety program to the F-CPU. The CPU enters STOP if configured to do so, then RUN with the new F-signature.
6. Verify the F-signature in the CPU properties under "Protection & Security > Safety > F-Signature".

This path is the only one accepted by TIA Portal for changing safety-relevant behavior at runtime. It is fully documented in the Addressing F-I/O and Configuring F-I/O sections of the TIA Portal Safety manual.

Workaround: PLCSIM for F-IO Functional Verification

For functional verification of safety logic without a real wired F-I/O, Siemens offers PLCSIM Advanced (S7-PLCSIM V15 and later) or the integrated PLCSIM in newer TIA Portal versions. The simulation does not enforce PROFIsafe wire-level integrity, which means that the simulated F-I/O image can be observed and influenced through the standard VAT during the simulation session. This is a legitimate engineering practice for unit-testing the safety program logic in the office before the FAT/SAT at the machine.

The procedure is as follows:

1. Compile the safety program to generate the simulation image.
2. Start PLCSIM and select the F-CPU type (for example, CPU 1516F-2 PN).
3. Download the entire project (standard + safety program) to the simulated F-CPU.
4. Establish the online connection. The simulated F-CPU reports the same protection level and F-password dialog as the real CPU.
5. Authenticate with the F-password.
6. Open a Watch Table that contains the F-I/O tags. In PLCSIM, the F-I/O image is exposed to the VAT exactly the same way that the standard process image is exposed.
7. Use the "Modify" column to set the simulated F-I/O value. The safety logic reacts instantly because PLCSIM does not perform PROFIsafe wire-level CRC validation.
8. Step through the safety program in the editor to verify the logic. The F-signature remains unchanged because no safety program change has been made.

Forcing F-IO on Real Hardware: What Is and Is Not Supported

Siemens does not provide a generic "force" function for F-I/O on real hardware, and for good reason. Forcing a safety input or output on a running machine would allow an operator to mask a genuine safety hazard, which is unacceptable in any SIL/PL application. The only supported mechanisms for influencing F-IO on real hardware are:

• F-Acknowledgment (F-Ack): A safety-integrated acknowledgment that clears a latched passivation condition after the operator has confirmed that the affected zone is safe. F-Ack is implemented as a function block in the safety program (typically ACK_OP for channel-level acknowledgment or ACK_GL for global acknowledgment) and is logged in the F-runtime group diagnostics.
• Channel-level re-integration: After a discrepancy error or sensor fault, the affected F-I/O channel can be re-integrated using the acknowledgment block. The re-integration does not change the F-I/O value; it only clears the passivation bit.
• Operator override via standard logic: Where the safety standard permits (e.g., maintenance mode with reduced speed, hold-to-run pendant), the safety program can be written to accept a standard non-safety input as a permissive. The safety-critical decision must always be made by the F-runtime group; the standard input only enables a non-safety branch.
• Engineering change to the safety program: The only way to change a safety value at runtime is to modify the safety program, recompile, and download. The F-password, F-signature, and STOP-to-RUN transition ensure that the change is intentional and audited.

Configuring F-I/O Parameters in Detail

Before any commissioning, the F-I/O modules must be configured with the correct F-parameters. The configuration is performed in the device or network view of TIA Portal:

1. Select the F-I/O module in the project tree (for example, an ET 200SP F-DI 8x24VDC HF or an F-DO 4x24VDC/2A PM).
2. Open the module properties by double-clicking the module.
3. Navigate to the F-parameters tab. The following fields are mandatory and must match the F-CPU configuration:

After configuration, the safety program must be compiled. TIA Portal will produce an F-IO DB and update the F-signature. Download the configuration to the F-CPU, then download the F-I/O configuration to the modules. The download sequence is important: the F-CPU must be online and the F-password authenticated before the F-I/O configuration can be pushed to the modules.

Common F-I/O Diagnostics and Error Codes

Comparison: Real F-CPU vs PLCSIM F-CPU

Verification Checklist

After any change to the safety program or F-I/O configuration, perform the following verification steps:

1. Compare the F-signature in the TIA Portal project with the F-signature in the online F-CPU. They must match exactly.
2. Read the F-I/O diagnostics buffer of every F-module. No "F-Communication error" or "F-Watchdog timeout" should be present.
3. Force a passivation event (for example, disconnect one channel of a redundant F-input) and verify that the F-runtime group enters the safe state.
4. Perform an F-Ack and verify that the channel re-integrates without re-cycling power.
5. Run the application-specific safety function tests (e-stop, light curtain, guard door interlock, two-hand control) and verify the stop category and response time against the safety requirement specification.
6. Verify the value status bits in the F-I/O DB; a passivated channel must report value status = 0.
7. Sign and date the safety acceptance protocol. File the F-signature, the F-I/O configuration printout, and the test report together.

Frequently Asked Questions