System Constants in TIA Portal Safety F-Programs: S7-1500

Overview

Siemens TIA Portal auto-generates system constants (HW identifiers such as HW_IO, HW_Interface, HW_Device, HW_SubModule, HW_Any, and OB_ANY) when a device configuration is compiled for an S7-1200 or S7-1500 station. Those constants give the standard user program a symbolic handle to every I/O channel, PROFINET interface, and module in the device view. In a safety program (F-program) running on an F-CPU such as CPU 1516F-3 PN/DP, CPU 1515F-2 PN, or one of the S7-1200 FC variants, those same system constants are not visible in the F-symbol table. The safety compiler rejects any reference to a standard PLC tag type from inside an F-runtime group, and it does so for architectural reasons rooted in EN ISO 13849-1 and IEC 61508, not for IDE convenience. The approved way to read the equivalent process and diagnostic information from the F-program is the F-I/O DB, the RTGx_SysInfo block, and the F-shared DB (F_GLOBDB) generated by the TIA Portal Safety compiler. This reference explains the architectural reason for the restriction, the approved data sources, the step-by-step procedure to read channel and diagnostic data in F-LAD or F-FBD, and the acceptance test required before the modified safety program may be commissioned in a SIL 3 / PL e installation.

System Constants in TIA Portal: Definition and Scope

When the TIA Portal hardware catalog is compiled against an S7-1500 or S7-1200 station, the project editor produces a set of system constants for every configurable object in the device view. They are visible in the PLC tag table under the System Constants tab and appear as named identifiers of data type HW_IO, HW_Interface, HW_Device, HW_SubModule, HW_Any, or OB_ANY. Typical use cases inside the standard program include:

• Calling RDREC / WRREC with a hardware identifier passed to the HARDWARE input.
• Evaluating IOXS_FAULT from the PROFINET diagnostics blocks.
• Performing module-level passivation with DPSA on PROFINET IO.
• Determining which port became disconnected through PNDP with record 0x802A.

The complete enumeration and the meaning of each identifier are documented in the official Siemens support FAQ ID 78782835 – Meaning of the system constants in STEP 7 (TIA Portal) with S7-1200/S7-1500. That FAQ is the authoritative reference for the standard symbol table.

Safety Program Architecture and the F-Symbol Table

An F-CPU executes two programs in parallel: the standard user program and one or more F-runtime groups. Each F-runtime group contains F-blocks (F-OB, F-FB, F-FC, F-DB) compiled with the F-Compiler, and it runs under a hardware watchdog. The F-Compiler generates a private symbol table for each F-runtime group. Tags in that table are the only identifiers an F-block can legally reference. The runtime group interface is a set of automatically generated data blocks that form the only data exchange point between the standard program and the safety program.

The data blocks that the safety compiler generates and the rules for accessing them are summarized in the table below.

The F-I/O DB is the direct replacement for the HW_IO system constant in a safety context. It exposes the same channel and diagnostic information that the standard program would read from a standard DI/DO module, but it does so through an F-certified data interface that the F-Compiler can statically verify.

Why HW_IO Constants Are Rejected in F-Programs

The F-Compiler enforces a closed-world rule: every input of an F-block that consumes a process value, every tag used in a safety-relevant comparison, and every channel address referenced by an F-FB must be resolvable to a fixed address at compile time, and it must originate from a safety-aware data source. Standard PLC tags and system constants fail this rule for two reasons.

1. Namespace separation. The F-program lives in its own symbol table. System constants are added to the standard symbol table; they are not visible inside the F-symbol table and therefore cannot be referenced from F-LAD, F-FBD, or F-SCL.
2. Diagnostic semantics. Many HW_IO constants are consumed by RDREC, WRREC, or the standard PROFINET diagnostics blocks. Those blocks are not on the F-certified block list. Reading a PROFINET port status through PNDP from inside an F-runtime group would make the F-CPU a witness to non-safety data without the runtime guarantee that the value is consistent with the safety process image.

The reference manual that lists the allowed and forbidden operations in F-LAD and F-FBD is the S7-1500 / ET 200MP – SIMATIC Safety – Configuring and Programming function manual, available on the Siemens support portal under entry ID 109751824. The Restrictions in the programming languages FBD/LAD section of that manual is the authoritative source for what is and is not permitted inside an F-runtime group.

Approved Data Sources for F-Logic

Inside an F-runtime group the engineer is restricted to three classes of data source. The mapping from the standard-program use case to the F-program equivalent is shown below.

F_GLOBDB: The Safety-Standard Handshake Area

The F-shared DB (F_GLOBDB) is the only DB that the safety compiler allows to be read and written from both worlds. The default name assigned by the Safety administration editor is F_GLOBDB; it can be renamed, but the name must start with F_ to be visible to the safety compiler. Typical user-defined content:

// F_GLOBDB - edited by the user, visible to both worlds
DATA_BLOCK "F_GLOBDB"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
   VAR
      // Standard -> F: mode selections
      Cmd_StartAck   : BOOL;        // Operator command from HMI, debounced in standard
      Cmd_AutoMode   : BOOL;        // TRUE = automatic, FALSE = manual
      Cmd_Muting1    : BOOL;        // Muting pair 1 enable
      Cmd_Muting2    : BOOL;        // Muting pair 2 enable
      // F -> Standard: status to display
      Status_SafeStopActive : BOOL; // TRUE while safe stop is enforced
      Status_EStopActive    : BOOL; // TRUE while E-Stop chain is open
      Status_Port1Lost      : BOOL; // PROFINET port 1 disconnect
      Status_Port2Lost      : BOOL; // PROFINET port 2 disconnect
      // Word-level aggregate for HMI efficiency
      StatusWord     : WORD;        // B0=EStop, B1=SafeStop, B2=Muting, B3..7=diag
   END_VAR
END_DATA_BLOCK

Inside the F-runtime group every write to F_GLOBDB is a candidate for safety review; inside the standard program every read of F_GLOBDB is non-safety and can be displayed, archived, or used for control flow without affecting the safety integrity.

RTGx_SysInfo: Runtime-Group Status Interface

The safety compiler generates one RTGx_SysInfo DB per F-runtime group (x = 1 to 8). The block exposes the runtime group interface defined by the SIMATIC Safety specification. The default TIA Portal V17 / V18 symbol layout for RTG1_SysInfo:

The exact bit assignment of Diag is documented in the SIMATIC Safety – Configuring and Programming function manual; it changes between TIA Portal major versions, so always consult the manual that ships with the installed TIA Portal version (V15.1, V16, V17, V18).

F-I/O DB: Channel and Quality Data

For every F-I/O module placed in the device view (for example an ET 200SP 6ES7136-6BA00-0CA0 F-DI 8x24V HF, or a 6ES7136-6DB00-0CA0 F-DQ 4x24V/2A), the safety compiler generates an F-I/O DB whose default name is the F-I/O's HW identifier followed by _DB. The relevant tags vary by module type, but the common surface is:

// Generated F-I/O DB for a 6ES7136-6BA00-0CA0 (F-DI 8x24V HF)
DATA_BLOCK "F-DI8_1_DB"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
   VAR
      Input         : ARRAY[0..7] OF BOOL;   // Channel process values
      QBAD          : BOOL;                  // Quality: 1 = value invalid
      ACK_REQ       : BOOL;                  // 1 = user must acknowledge fault
      Diag          : WORD;                  // Channel-level diagnostics
      PASS_ON       : BOOL;                  // Passivation output state
      ACK           : BOOL;                  // Acknowledge from F-program
   END_VAR
END_DATA_BLOCK

The Diag WORD bit assignment for the F-DI 8x24V HF module is module-specific. Bits 0 to 7 map to channels 0 to 7; a set bit means "channel fault active" (wire break, short circuit, discrepancy error). Bits 8 to 15 are module-level (sensor supply, internal comms, etc.). Refer to the F-I/O Modules – Device Manual for the specific catalog number, available on the Siemens support portal under the article ID for the module.

Mapping Standard Diagnostics to Safety-Approved Sources

The following table covers the diagnostic values that standard programs typically read from PROFINET or PROFIsafe modules, together with the F-program equivalent.

Step-by-Step: Reading a PROFINET Port Disconnect in F-Logic

The following procedure demonstrates how to read a PROFINET port diagnostic from the F-program without calling PNDP directly. The pattern keeps the F-runtime group F-certified while still giving the HMI the port-level detail that Siemens displays in Online & Diagnostics.

1. Create the F-shared DB. In the Safety administration editor, add an F-shared DB named F_GLOBDB and declare the bits Status_Port1Lost and Status_Port2Lost as BOOL.
2. Build the F-runtime group. Add an F-OB (for example Main_Safety_RTG1) and a user F-FB (for example FB_SafeDiag) called from the F-OB. Place the F-runtime group on the F-CPU's task list at the cycle time mandated by your safety calculation, typically 5 ms to 50 ms.
3. Read module-level diagnostics. Inside FB_SafeDiag, open the F-I/O DBs in symbolic mode and read QBAD and Diag. Use the module's device manual to map the bits to the physical port.
4. Map the bit to F_GLOBDB. Assign the result of the bit decoding to F_GLOBDB.Status_Port1Lost. Wrap the assignment in a direct F-CPU := operation; do not use any pointer or VARIANT in the F-program.
5. Have the standard program call PNDP. In the standard cyclic OB (e.g. OB1), read F_GLOBDB.Status_Port1Lost and call PNDP with the original HW_Interface system constant. The result is forwarded to the HMI; the F-program remains untouched.
6. Display on HMI. On a WinCC Unified or WinCC Professional screen, bind an indicator to the standard tag that holds the PNDP result. The F-CPU, the safety compiler, and the certificate remain unaffected.
7. Run the acceptance test. Disconnect each PROFINET cable in turn; verify that the F-runtime group records the passivation, that the corresponding Status_PortxLost bit in F_GLOBDB becomes TRUE within one watchdog cycle, and that the HMI shows the correct port.

Firmware and TIA Portal Version Compatibility

The symbol names, the data types, and the F-Compiler error messages change between major versions. The table below captures the configurations in which the F-shared DB, RTGx_SysInfo, and F-I/O DB are generated in their current form. The article assumes the TIA Portal V17 / V18 conventions unless explicitly noted.

For S7-1200 F-CPUs, only a single F-runtime group is allowed; the F-shared DB and the F-I/O DB are generated, but RTGx_SysInfo is delivered as RTG1_SysInfo only. Check the device manual of the specific catalog number before depending on a particular tag layout.

Verification, Acceptance Test, and Troubleshooting

A change that touches the F-program, the F-shared DB, or any F-I/O DB requires a partial or full safety acceptance test in accordance with EN ISO 13849-1:2023 (PL e) and IEC 61508 (SIL 3). The minimum verification steps are:

1. Compile clean. The Safety editor must report "Safety program generation completed without errors" in the Safety administration log. Any warning about non-safety blocks being referenced must be resolved.
2. Compare F-CPU signature. Read the F-CPU's safety signature with Online → Safety → Show F-signature. The value must match the value stored in the project.
3. Online & Diagnostics. Open the F-runtime group in online mode. Confirm that the cycle time, the watchdog time, and the passivation count match the design.
4. Force / watch table. Use a watch table on the F-I/O DB to set QBAD = TRUE (simulate passivation) and verify that RTGx_SysInfo.Passivation latches, that ResetRequest is set, and that F_GLOBDB status bits react as designed.
5. Functional test of E-Stop / safe stop. Trigger every safety input (E-Stop, light curtain, guard door) and confirm the safety output de-energizes within the calculated response time.
6. Sign-off. Update the safety validation matrix and have the safety engineer and the machinery integrator sign the change record.

Troubleshooting Matrix

Field-Proven Patterns and Caveats

From a controls-engineering perspective, four patterns appear repeatedly in real installations.

1. The F-shared DB must be the only handshake. Do not write a standard DB from the F-program "because the standard tag table is more convenient." The safety compiler will either reject the write or, worse, accept it under an F-DB and break the symbol-table separation. The only DB that crosses the boundary is the F-shared DB whose name starts with F_.

2. Do not read standard PROFINET diagnostics from the F-program. A PROFINET diagnostic block such as PNDP, DPNRMV, or DPRD_DAT / DPWR_DAT is not on the F-certified block list. The TIA Portal safety compiler will refuse to compile a call to those blocks inside an F-runtime group.

3. Plan the F-I/O DB before you commission the F-I/O. Renaming an F-I/O after first compilation may rename the F-I/O DB. If the F-program references the old name, the next compile will fail. Re-synchronize the project, then re-run the acceptance test.

4. F-programmers do not need PROFINET topology data. The F-CPU exchanges PROFIsafe frames with the F-I/O over PROFINET, but it does so through the F-I/O DB, not through PROFINET system constants. The standard program continues to use the system constants for the topology view; the F-program stays isolated.