S7-400H Fault-Tolerant PROFINET Communication Configuration Guide

Overview of S7-400H Fault-Tolerant Communication

SIMATIC S7-400H fault-tolerant systems deliver redundant CPU operation for process applications that cannot tolerate a controller outage. Each H-station contains two CPUs of identical type running in master/reserve mode, synchronized over fiber-optic sync modules. If the active CPU fails, the standby takes over within a defined switchover time without losing the in-process state. The H-system extends this redundancy to the communications layer through fault-tolerant S7 connections routed over one CP 443-1 per H-CPU, so a single CP or PROFINET ring failure does not break the link to the partner controller.

Fault-tolerant S7 communication is implemented by deploying the standard S7 communication SFBs (USEND/URCV, BSEND/BRCV, GET/PUT) over a connection of type "S7 connection fault-tolerant" in NetPro or the TIA Portal connection editor. The OS multiplexes the SFB call onto the first available CP path; user code does not see the redundancy at the block call level except for the connection ID and the diagnostic return values.

Hardware Architecture and Compatibility

A reference configuration for two redundant S7-400H stations communicating over PROFINET uses the following components. The active partner runs the higher-performance CPU; the passive partner may run a smaller H-CPU as long as it supports the same fault-tolerant connection type.

Each H-CPU is connected to its own CP 443-1 through the backplane (PN/PN interface slot). The CPs are then linked to a common PROFINET ring or a dual-attached managed switch fabric. Both H-stations sit in the same IP subnet; the fault-tolerant S7 connection is configured against the partner IP of each CP, but user code calls a single connection ID that the OS resolves at runtime.

Software and Firmware Prerequisites

Reference: SIMATIC S7-400H Fault-Tolerant Systems Manual (entry 82478488), chapter 11 "Communication".

PROFINET Topology for H-Systems

The H-station's PROFINET ring or star topology must give each CP 443-1 an independent physical path to the partner H-station. A typical layout is a managed PROFINET ring with the SCALANCE XC-200 or XM-400 in MRP role, with the two CP 443-1 ports of the partner H-station and the two CP 443-1 ports of the local H-station each attached to the ring as MRP clients. A redundant S7 connection survives a single cable break, a single managed switch failure, and a single CP failure without user intervention.

   H-Station 1                                H-Station 2
   +------------+        PROFINET ring        +------------+
   | CPU 0     |       /-------------\       | CPU 0     |
   | CP 443-1  +--port-+  SCALANCE   +--port-+ CP 443-1  |
   | (active)  |       |  (MRP mgr)  |       | (active)  |
   +------------+       \-------------/       +------------+
   | CPU 1     |                              | CPU 1     |
   | CP 443-1  +--port-+            +--port-+ CP 443-1  |
   | (standby) |       |            |       | (standby) |
   +------------+       +------------+       +------------+
        (fiber-optic sync between CPU 0 and CPU 1 inside each station)

Configuring Fault-Tolerant S7 Connections in STEP 7

The connection is configured once in NetPro and downloaded to both H-CPUs. The configuration generates an Instance Data Block (IDB) that user code references by its symbol.

1. Open the SIMATIC Manager and load the H-station project.
2. Select the active CPU and double-click "NetPro".
3. Right-click on the CPU of the active H-station and choose "Insert New Connection".
4. In the Insert New Connection dialog select partner station "H-Station 2" (the partner H-CPU, not the partner CP), and connection type "S7 connection fault-tolerant". Click "OK".
5. Open the connection properties. Under "General" verify the connection ID (for example ID 1). Under "Connection Path", the OS automatically distributes the path to both CPs of both H-stations (two physical routes). No user input is required.
6. Compile and download the connection to all H-CPUs. The OS downloads the connection to both the active and standby CPU of each H-station.
7. Open the program blocks of the active CPU and locate the automatically generated IDB. The default symbolic name is "IDB_CONN_1" or as configured in the connection properties. The same IDB exists on the standby CPU.

Configuring Fault-Tolerant S7 Connections in TIA Portal

From TIA Portal V15.1 onward, the S7-400H is supported as a target. NetPro is replaced by the project-tree "Connections" view.

1. Open the TIA Portal project containing both H-stations.
2. Navigate to "Devices & Networks" and select the first H-CPU.
3. Click "Connections" at the top, then the connector icon to add a new connection.
4. Set partner to the second H-station's active CPU and select type "S7 connection fault-tolerant".
5. Open the connection properties. Note the automatically assigned "ID" (decimal) and verify that the connection path includes both CP 443-1 of both H-stations. Under "Address details" the OS shows the two local and two partner interface end points.
6. Compile and download to all targets. The connection IDB is generated in the "Program blocks / System blocks" folder of each H-CPU.

Reference: Siemens support entry 109751566: Configuring fault-tolerant S7 connections and the TIA Portal information system under "Configuring connections > S7 connection fault-tolerant".

Programming S7 Communication SFBs

Once the connection is configured, user code calls one of the standard S7 communication SFBs against the connection IDB. The OS handles redundancy entirely; user code does not need to know which CP is currently active.

Sample BSEND Call in Structured Text (SCL)

// SFB 12 (BSEND) call against fault-tolerant S7 connection
// IDB_CONN_1 is the instance DB generated by NetPro / TIA Portal
#REQ        := TRUE;                              // Trigger send on positive edge
#R          := FALSE;                             // No abort
#ID         := WORD_TO_INT("IDB_CONN_1".ID);     // Connection ID from IDB
#SD_1       := P#DB_TX.DBX 0.0 BYTE 480;          // Any pointer area; up to 32 KB
#LEN        := 480;                               // Send length in bytes
#DONE       := "tagSendDone";                     // TRUE on successful completion
#ERROR      := "tagSendError";                    // TRUE on error
#STATUS     := "tagSendStatus";                   // W#16# status word
#SD_2..SD_4 := 0;                                 // Unused for short sends

Sample BRCV Call in Structured Text (SCL)

// SFB 13 (BRCV) call against fault-tolerant S7 connection
#EN_R       := TRUE;                              // Always ready to receive
#R          := FALSE;
#ID         := WORD_TO_INT("IDB_CONN_1".ID);
#RD_1       := P#DB_RX.DBX 0.0 BYTE 480;          // Receive buffer
#LEN        := "tagRcvLen";                       // Actual bytes received
#NDR        := "tagRcvNDR";                       // New data received
#ERROR      := "tagRcvError";
#STATUS     := "tagRcvStatus";

Sample GET Call in Ladder (FBD excerpt)

#REQ        TRUE  -> SFB14.GET
#ID         W#16#0001 --> SFB14.GET.ID
#ADDR_1     P#M 100.0 BYTE 20 --> SFB14.GET.ADDR_1
#RD_1       P#DB_RX.DBX 0.0 BYTE 20 --> SFB14.GET.RD_1
NDR    SFB14.GET.NDR --> "tagRcvNDR"
ERROR  SFB14.GET.ERROR --> "tagRcvError"
STATUS SFB14.GET.STATUS --> "tagRcvStatus"

Why AG_SEND/AG_RECEIVE Are Not Applicable

AG_SEND (FC 5) and AG_RECEIVE (FC 6) belong to the legacy SEND/RECEIVE interface that exposes the raw transport connection of an S7-CP. They operate on a single configured transport connection identified by the L_ADDR parameter, which holds the CP's hardware identifier (the "base address" of the transport channel). The legacy interface does not understand S7-400H redundancy: it only ever binds to one physical path. If the active CP of an H-station fails, AG_SEND on the partner station does not automatically fail over to the standby CP of the partner; user code must detect the failure, close the transport connection, and re-open it on the second CP. This is not "fault-tolerant communication" in the S7-400H sense and is not the recommended path.

Use the S7 communication SFBs (USEND, URCV, BSEND, BRCV, GET, PUT) over a "S7 connection fault-tolerant" instead. The OS automatically distributes the call across both CPs of both H-stations and survives CP and link failures. The L_ADDR input that the question raises is simply not part of these SFBs; you specify the connection by its ID parameter, and the connection itself has been previously created in NetPro or TIA Portal.

L_ADDR Clarification for H-Systems

The S7 connection fault-tolerant exposes a single connection ID. User code calls the SFB with that ID, and the OS resolves the redundant path. From the application's perspective there is one logical connection with one ID, although the OS internally maintains two physical routes.

Diagnostics and Status Monitoring

Field diagnostics for fault-tolerant S7 connections are obtained from three sources:

1. SFB STATUS output. Every S7 communication SFB returns a 16-bit STATUS. W#16#0000 indicates OK. Codes W#16#0001..00FF describe the local connection state. Codes W#16#8001..80FF describe error conditions such as partner unreachable, resource busy, or CP failure.
2. FB 55 STATUS_S7. Place this system FB in the OB 1 or a cyclic OB. It scans the connection table and returns the operational state of every S7 connection. A fault-tolerant connection reports its current active path so you can verify which CP is carrying traffic.
3. CP and CPU diagnostic buffer. Open the online diagnostics of the CP 443-1 in STEP 7 / TIA Portal. The buffer lists connection establishment, link-down, link-up, and partner-not-reachable events for both physical paths.

Reference: CPU 417-5H PN/DP manual (entry 111774926) and CP 443-1 manual (entry 24423175) for full diagnostic event lists.

STATUS_S7 Sample Call

// Cyclic OB 1, scan all S7 connections
CALL FB 55, "DB_StatusS7"
  MODE        := 1                // 1 = scan only active connections
  LADDR       := 0                // 0 = scan all, otherwise local CP HW ID
  RET_VAL     := "tagStatusRet"   // Return code (0 = OK)
  BUSY        := "tagStatusBusy"
  CONN_STAT   := "arrConnStat"    // Array of WORDs, one per connection

Commissioning and Verification

1. Compile and download the H-station hardware configuration. Both CPUs and both CPs of each H-station must report "OK" in the online view.
2. Verify the CPU-CPU fiber-optic link is up on both H-stations. The "H System Status" view should show "System in RUN with redundancy".
3. Compile and download the NetPro / TIA Portal connections. Confirm that the fault-tolerant S7 connection shows "established" on both H-stations.
4. Insert a watch table on each H-CPU with one tag at the start of the BSEND SD_1 area and one tag at the BRCV RD_1 area. Trigger a BSEND and confirm the partner side updates within a few OB 1 cycles.
5. Test CP failover. Disconnect the PROFINET cable from the active CP of the partner H-station. The connection should remain "established" and BSEND/BRCV cycles should continue. STATUS_S7 should now report the second physical path as the active route.
6. Test CPU failover. From STEP 7 / TIA Portal, force the active H-CPU of the partner to STOP. The partner standby takes over. The fault-tolerant S7 connection should automatically re-establish on the new active CPU, typically within 100 ms to 3 s depending on the configured monitor time.
7. Test simultaneous link and CP failure. Disconnect both the active PROFINET cable and power the partner's active CP off. The connection should re-establish over the standby CP within the configured monitor time (default 30 s, can be reduced to 100 ms for high-availability applications).
8. Reconnect everything. Confirm via STATUS_S7 that both physical paths are back in service.

Performance, Cycle, and Sizing Considerations

The BSEND/BRCV cycle time on a fault-tolerant S7 connection is the sum of the path latency plus the OS processing overhead. On PROFINET with two CP 443-1 in a ring, expect 30-80 ms per BSEND/BRCV cycle for a 480-byte payload. USEND/URCV is faster (10-30 ms) but is not acknowledged, so use it only for cyclic state broadcasts. GET/PUT latency is similar to BSEND/BRCV for short payloads.

The connection monitor time (set in NetPro / TIA Portal under "Connection Properties > Operating Mode") controls how long the OS waits before declaring a path down. The default is 30 s. For high-availability applications set this to 100 ms for fast failover; the trade-off is increased probability of a false failover on a transient network blip.

Common Configuration Pitfalls

Field-Proven Caveats

• On H-stations, the connection IDB exists on both CPUs. STEP 7 / TIA Portal download propagates the same IDB to the standby so that after a CPU failover user code continues to find a valid IDB.
• BSEND/BRCV buffers the full payload in the IDB. The SFB copy operation runs in the OB 1 priority. For payloads over 4 KB, call BSEND/BRCV from a low-priority cyclic OB (OB 30-OB 38) to avoid OB 1 overrun.
• When the standby CPU takes over after a fault, in-flight BSEND telegrams are lost. The SFB returns STATUS W#16#80A2 ("partner CPU in STOP") or the DONE bit stays FALSE. The application must implement its own retry / sequence number logic if guaranteed delivery is required.
• PROFINET redundancy is required at the network level to survive a single link break. Without MRP or a redundant switch fabric, a single cable break is enough to drop the connection.
• Some early CP 443-1EX20-0XE0 firmware revisions (

FAQ