Transfer Safety DBs Between S7-1500 PLCs via PROFINET I-Device

Problem Overview: Exchanging Safety Data Between Two PLCs

Engineers frequently ask whether standard SIMATIC PUT / GET instructions can carry a safety data block (F-DB) from one S7-1500F to another S7-1500F. The short answer is no: the F-runtime group is segregated from the standard user program, and PUT / GET are non-safety communication services that operate only inside the standard program context. Treating PUT / GET as a transport for fail-safe data breaks the PROFIsafe protocol contract because no CRC signature, sequence counter, or F-destination address is appended to the payload.

For a properly certified safety path, you must use a safety protocol designed for cross-controller fail-safe communication. On Siemens controllers, that path is the PROFIsafe profile running on top of PROFINET I-Device, secured at both ends with the SENDDP and RCVDP function blocks from the F-library. This article covers the protocol mechanics, the TIA Portal V20 configuration, the F-parameter set, the verification procedure, and the cross-vendor alternatives offered by ABB and Schneider Electric.

Why Standard PUT/GET Fails for Safety Data

The PUT and GET instructions (S7-1500: PUT / GET; S7-300/400: legacy PUT / GET via SFB/SFC) are classified by Siemens as non-secure, non-safe user-program communication. They are routed through the standard communication stack of the CPU, the same path that carries HMI traffic, S7 routing, and open TCP. They support no CRC-16, no PROFIsafe sequence counter, no F-source/F-destination address, and no passivation. The receiving F-CPU cannot validate the telegram, so the F-runtime group would either reject the data outright or, worse, treat it as valid and act on it.

The PROFIsafe V2.6.1 telegram wrapped around the payload looks like this:

None of these fields is generated by PUT or GET. Without them, the receiving F-CPU would have no way to detect a stuck-at, repetition, corruption, delay, insertion, or masquerade fault - the exact faults the IEC 61784-3-3 black-channel model must defend against.

PROFINET I-Device Communication with PROFIsafe

The PROFINET I-Device function lets an S7-1500 controller act as a lower-level PROFINET device to a higher-level S7-1500 controller, exposing a configured I/O range that the higher-level PLC can read and write deterministically. When the I-Device is an F-CPU, the I/O slots can contain PROFIsafe slots. The I-Device therefore acts as a PROFIsafe proxy: the higher-level F-CPU sees standard PROFINET slots, and the lower-level F-CPU tunnels fail-safe process values to its own F-runtime group.

For a bidirectional safety link, two I-Device relationships are required - one where PLC A is the controller and PLC B is the I-Device, and another where PLC B is the controller and PLC A is the I-Device. The I-Device exchange is then treated as a single PROFIsafe channel for the F-application.

For the S7-1500F family, the relevant F-CPUs are CPU 1511F-1 PN, CPU 1512F-1 PN, CPU 1513F-1 PN, CPU 1515F-2 PN, CPU 1516F-3 PN/DP, CPU 1517F-3 PN/DP, and CPU 1518F-4 PN/DP MFP. The CPU 1510SP F-1 PN and CPU 1512SP F-1 PN (ET 200SP) are also valid when the controller is decentralized. Required firmware: V2.9 or later for the S7-1500F; V2.9 SP1 or later for the ET 200SP F-CPU to support PROFIsafe V2.6.1.

Siemens SENDDP and RCVDP Safety Communication Blocks

Inside the F-program, the cross-controller safety payload is handled by two blocks from the F-Library shipped with the SIMATIC Safety option in TIA Portal:

• SENDDP (F-SENDDP) - sender block that packages an F-DB (or portions of it) into a PROFIsafe slot in the I-Device area.
• RCVDP (F-RCVDP) - receiver block that unpacks the PROFIsafe slot and writes the F-signal into a target F-DB on the second F-CPU.

Both blocks live inside the F-runtime group and call the lower-level F-I/O-DB / F-DB access primitives F_IO_TN / F_IO_TS. They must be placed inside the F-runtime group, never the standard OB1, and the F-monitoring time must be set longer than the worst-case PROFIsafe cycle (typically 1.5x the configured update time plus jitter).

Configuring Safety Communication in TIA Portal V20

Use the following procedure to establish an I-Device + PROFIsafe link between two S7-1500F controllers. The TIA Portal V20 release introduces the consolidated safety administration editor that combines F-CPU parameters, F-shared DBs, and the F-runtime group signature in one view. The full configuration guide is published in the SIMATIC Safety Configuring and Programming manual for TIA Portal V20.

1. Activate the I-Device role. In the device view of PLC A, open Properties > PROFINET interface > Operating mode > I-Device, tick "I-Device functionality" and define the transfer area (e.g. 16 bytes input / 16 bytes output). Repeat on PLC B in the reverse direction.
2. Insert a PROFIsafe slot. In the I-Device transfer area on PLC A, drag the PROFIsafe V2.6.1 sub-module onto the slot. Assign the F-source address (F_Source_Add, e.g. 1) and F-destination address (F_Dest_Add, e.g. 2). On PLC B mirror the addresses (F_Source_Add = 2, F_Dest_Add = 1).
3. Assign the F-DB. In the F-program of PLC A, add the F-DB that will be sent, ensure the F-attribute is set, and call SENDDP with the slot's HW-IO address and the F-DB handle. In PLC B, create the matching F-DB (same name length, same F_TYPE) and call RCVDP.
4. Configure the F-monitoring time. Default = 100 ms. Increase to a value safely larger than 3x the PROFINET update time + 2x the F-runtime group cycle, e.g. 200 ms for a 32 ms update and 25 ms F-cycle.
5. Compile the safety program. TIA Portal generates the F-CRC signature and the safety signature. Both controllers must end up with identical safety signature values for the parameters (not for the program code itself, which can differ). Re-sign the safety program if the parameter mismatch error appears.
6. Download to both F-CPUs. Always download the standard program first, then the safety program. The CPU will refuse a safety download if the F-signature of the target differs from the offline value.
7. Verify QBAD on the receiver. In the F-program, add the RCVDP.QBAD signal to the safety logic - if QBAD = 1, the receiver must use the substitute value and drive the safe state for that input.

The I-Device topology is shown below. The dashed lines represent the safety tunnel; the solid lines represent the standard PROFINET process data area.

Cross-Vendor Safety Data Exchange: ABB and Schneider

When the second controller is not a Siemens F-CPU, the standard transport is the openSAFETY profile (used by ABB AC500-S) or Safety over EtherCAT (FSoE, used by Beckhoff and others). Each vendor implements its own version of the safety DB transfer. ABB's solution supports a maximum of 1440 bytes of process data plus up to 384 bytes of functional safety data, as documented in the ABB press release on the AC500-S cross-controller exchange. The data channel rides on a single Ethernet segment with the F-channel multiplexed into the same UDP frame as the process data.

Schneider Electric's Modicon M580 Safety PAC supports a similar model where the safety program and the standard process program run on the same M580 Safety CPU, with the safety logic written in EcoStruxure Control Expert (formerly Unity Pro) using the SAFEBLV (safety block library) and exchange zones for inter-zone data. The M580 Safety design separates safety zones from process zones; a transfer zone object bridges the two without duplicating memory, and the integrity of the F-side is enforced by the safety kernel.

Data Transfer Between the Safety Program and the Standard User Program

Even when the safety DB is correctly received on the second F-CPU, the F-program is sealed: the standard user program cannot read the F-DB directly and the F-DB cannot read the standard process image. The TIA Portal V20 manual section on data transfer from the safety program to the standard user program explicitly notes that the integrity of the safety program and the safety-related data is not checked on this hop. In other words, once you copy a value out of an F-DB into a standard DB, the value loses its safety classification.

The recommended pattern is to use a dedicated exchange DB with a defined, reviewed interface. The F-program writes into the exchange DB, the standard program reads from it (or vice versa). The exchange DB carries a name suffix (e.g. _SAFE_EXCHANGE) and is documented in the safety plan.

Commissioning and Verification Procedure

After download, perform the following verification steps before putting the safety path into service. Each step corresponds to a measurable pass criterion.

1. Inspect the safety diagnostics buffer. In TIA Portal, go Online > Diagnostics > Safety diagnostics. Verify the latest event is "F-system initialized" with no CRC or sequence-counter errors since last power-up.
2. Force a controlled passivation. In the Safety Administration Editor, click "Passivate F-I/O" for the receiving slot. Confirm that RCVDP.QBAD = 1 within one F-monitoring time and that the F-runtime group drives the safe state for the consumer.
3. Force an address mismatch. Temporarily set F_Dest_Add on the sender to 99. Re-download. The receiver should report CRC-1 error and the F-system should passivate within the F-monitoring time.
4. Re-acknowledge and verify recovery. Reset the address, re-download, send ACK from the standard program. Confirm QSUBS = 0 and QBAD = 0.
5. Measure end-to-end latency. Use a high-resolution PROFINET tap (e.g. Indu-Sol PROFINET-INspektor or Softing echoChange for TIA) to measure the round-trip from F-DB write on PLC A to F-DB read on PLC B. The result must be less than the configured F-monitoring time on both sides, with a 25% safety margin for jitter.
6. Run the black-channel test. Insert a managed switch with packet-drop / reordering simulation between the two controllers and confirm that the safety logic passivates within the F-monitoring time after three consecutive bad telegrams.
7. Sign the safety program. The safety signature must be identical on both F-CPUs for the parameters. Re-sign if any F-parameter was changed during the test.

Fault Codes and Troubleshooting Matrix

When the F-channel malfunctions, the diagnostic byte returned by RCVDP.DIAG and the F-system diagnostics buffer give a structured error class. The following matrix covers the field-typical faults.

For a controller-level interpretation, the SF (system fault) LED on the F-CPU and the diagnostic buffer entries cross-reference these DIAG values. The TIA Portal online Diagnostics > Safety diagnostics view translates the raw byte into a human-readable text for each entry above.

Safety Integrity Constraints and Best Practices

A cross-controller safety path adds latency, additional failure modes, and a second F-CPU's diagnostics. To stay inside the calculated PFD / PFH budget:

• One safety protocol per link. Do not bridge PROFIsafe to openSAFETY in the field. Use a single protocol end-to-end.
• Unique F-addresses network-wide. F_Source_Add and F_Dest_Add are 16-bit values 1..65534; allocate them from a documented register to avoid the 0x0D device address error.
• Set the F-monitoring time with margin. Field measurement typically yields 2..8 ms jitter on PROFINET. A 1.5x margin is the minimum, 2x is preferred.
• Document the exchange DB. Treat the F-DB as part of the safety plan; the safety signature covers parameter changes, not code changes.
• Validate substitute values. Every RCVDP consumer must use 0 (or a documented safe substitute) when QBAD = 1. A bare read of the F-DB without QBAD check is a SIL violation.
• Re-sign after every parameter change. The safety signature on both F-CPUs must be identical for the parameter set; otherwise the receiving F-CPU will refuse to enter safety mode.
• Plan a black-channel test in the SAT plan. Document a switch-induced packet drop and confirm that the F-system passivates within the F-monitoring time.