S7-400H CP443 IP Switchover: Configuration for Redundant Ethernet

Problem: CP443 IP Addresses Do Not Switch on S7-400H Failover

The SIMATIC S7-400H redundant PLC has two CPU racks (rack 0 master, rack 1 standby) and each rack typically hosts a CP 443-1 communications processor. CP0 and CP1 always receive different IP addresses during STEP 7 / HW Config configuration. When a CPU switchover occurs, the master role transfers to the standby CPU but the IP address associated with each CP remains bound to its physical Ethernet interface. The result: a Modbus TCP client, OPC server, or HMI that points to 192.168.0.1 (rack 0 CP) loses connection the moment rack 0 stops responding, even though rack 1 has fully taken over as master.

This is documented in the Siemens manual Redundant communication via the CP 443-1 in H-systems (Entry ID 109739212), which explicitly states that the two CPs must be configured with different IP addresses so that they can use the same TCP/UDP port numbers without conflict. The same document is the canonical reference for how to make external systems tolerate the failover.

The customer's expectation - that the master's IP address remains reachable across the failover - is a valid request, but it requires either application-level redundancy, network-level indirection, or a different hardware platform that natively supports address swap.

Root Cause: Why Siemens Does Not Swap the IP

The design choice is intentional. A routed IP address change inside a Siemens S7-400H would require the CPU to re-initialize the CP's TCP/IP stack and renegotiate all open connections - a process that takes several seconds. During that window, application data on the open connections is lost, because TCP must retransmit or the application session must be rebuilt. Siemens instead keeps both CPs online permanently with fixed, distinct IPs and presents the redundancy to the user as duplicated communication paths.

The relevant facts:

• CP0 and CP1 each have their own MAC, IP, subnet, and gateway. They are not interchangeable at the link layer.
• The CPU redundancy function (SWITCH, MASTER-RESERVE) operates on the backplane and does not interact with the CP's IP layer.
• An H-system does not implement VRRP (Virtual Router Redundancy Protocol) or HSRP between the two CP interfaces.
• Open TCP connections are owned by the CP that accepted them. After failover, those connections are no longer serviced by the new master CPU until re-established.

The Siemens position is that "redundant" in 400H terminology means two physically independent communication paths, not a virtual single endpoint. The PLC remains fully reachable; the path just changes.

Siemens Official Approach: Duplicated Communication Paths

Siemens documentation presents four options for connecting an HMI or SCADA client to an S7-400H system. The options are ranked by complexity and recovery time.

Option 4 is the most robust because it survives a CP fault as well as a CPU fault. If CPU A is master and CP C fails, CPU A still answers through CP D. If the entire rack 0 fails, CPU B answers through CP C and CP D. The application sees four potential endpoints and applies a preference rule (e.g., CPU A first, fall back to CPU B; per CP, primary CP first).

For a Modbus TCP client that cannot perform this multi-endpoint logic, the standard Siemens recommendation is to use a Siemens redundancy gateway (e.g., a WinCC station with two S7 connections and one Modbus server, or a SINAUT ST7 station). This is documented in the Siemens application example Redundant communication via the CP 443-1 in H-systems (Entry ID 109739212).

Configuration: Four-Connection Matrix with CP 443-1

The four-connection matrix is configured in two places: HW Config for the CP connections and STEP 7 for the partner connections.

HW Config Side

1. Open HW Config and select CP 443-1 in rack 0 (CP C). On the Ethernet interface properties, assign IP address 192.168.0.1, subnet mask 255.255.255.0, and check "Use router". Set the CP mode to "CP 443-1" (not "S7 communication only").
2. Repeat for CP 443-1 in rack 1 (CP D), assigning 192.168.0.2, same subnet mask.
3. On each CP, open the "S7 Communication" tab and define two unspecified S7 connections: one to the partner CPU-A-side OPC server, one to the partner CPU-B-side OPC server. The connection IDs are local to each CP and must be unique within that CP.
4. Repeat for CP D, defining mirror connections to the same two partner OPC servers.

Partner Side (OPC / HMI)

In the SCADA or OPC server, define four S7 connections with the following properties:

The application logic polls CONN_AC first. If no response is received within N seconds (typically 2x the poll interval), it falls back to CONN_AD, then CONN_BC, then CONN_BD. Tags are read from the highest-priority live connection.

Programmatic IP Assignment via FB55 (IP_CONFIG)

Siemens provides FB55 "IP_CONFIG" in the standard library SIMATIC_NET_CP for the CP 443-1. The block can be used to assign an IP address to the CP at runtime via INIT_AG or to reconfigure the CP. On an S7-400H this is technically possible, but the resulting behavior is not a clean swap.

Parameters of FB55

Behavior on S7-400H

Calling FB55 from CPU A against CP C causes CP C to drop its current IP and take the new one. All open TCP connections on CP C are closed; the partner (DCS client) sees a TCP RST or timeout. The new IP becomes active after the CP restart completes (typically 5-15 s for CP 443-1 EX20 and similar). This is not a sub-second failover.

The user's question about "assign IP from user program so that on the network there is only one CP" implicitly asks the CP to give up its IP and rejoin on the same address as its twin. This is not supported because the two CPs would briefly collide on ARP. The accepted workaround is to disable one CP (park it) and bring it online only after the other has failed - again, not sub-second.

Disabling the Standby CP

The CP 443-1 supports the "PG/OP channel disabled" and "CP stop" diagnostics. To minimize the network surface, you can:

1. Set CP D's IP to a non-routable address in HW Config (e.g., 0.0.0.0 or 169.254.x.x) so that it does not answer on the production subnet.
2. Configure CP D's connection properties to "passive" so it does not initiate outgoing connections.
3. Use FB55 with MODE=2 to stop CP D entirely after CPU B takes over as standby.

The cleanest implementation uses a startup OB (OB100) on each CPU that calls FB55 against its own rack's CP with the production IP, and a separate OB that calls FB55 against the partner rack's CP with a no-op address. This keeps exactly one CP live on each subnet at any given moment.

HMI Connection Options for S7-400H

For ProTool / WinCC Flexible / TIA Portal HMI panels, the official Siemens solution document lists the four options above plus a fifth option using "S7 Routing" through the backplane. The most common production setup is Option 4: define two HMI connections in the panel project, one pointing to 192.168.0.1 and one to 192.168.0.2, and let WinCC Flexible's area pointer / status bit decide which is active.

In TIA Portal V18 and later, the panel's "Connection" editor exposes the redundancy mode "S7-400H redundant". When this mode is selected, the panel automatically opens two S7 connections, monitors their integrity, and switches the active path within one update cycle.

Router-Based and NAT-Based Solutions

If the DCS / HMI cannot be modified to talk to two IPs, the indirection must live on the network. Common approaches:

Industrial Router with NAT and Tracking

Deploy a managed industrial router (e.g., SCALANCE S615, SCALANCE M876, or a third-party device) on the PLC side. Configure a static NAT mapping:

Inside Local:   192.168.0.1:502  (CP0, Modbus TCP)
Inside Global:  10.0.0.1:502

Inside Local:   192.168.0.2:502  (CP1, Modbus TCP)
Inside Global:  10.0.0.1:502

The router must then rewrite inbound traffic on 10.0.0.1:502 to whichever CP is currently the master. This requires a router that supports conditional NAT with a health-check trigger (an ICMP poll of both CPs). The SCALANCE M-800 / S615 series supports this via its "Connection Tracking" and "Firewall Stateful Inspection" features when configured with a script.

External Redundancy Gateway PC

A small Windows or Linux PC running two Modbus TCP server instances (one bound to CP0, one bound to CP1) presents a single virtual IP to the DCS. The PC monitors both CPs and forwards requests to the active one. Latency: 5-10 ms per transaction. Drawbacks: single point of failure, additional hardware, additional licensing.

Layer-2 Bypass Relay

Two single-pole double-throw (SPDT) relays, controlled by the CPU's "Master Active" relay output, switch the Ethernet pair between the active CP and the inactive one. This hardware approach achieves sub-100 ms failover but is rarely used because it requires careful EMC design and fails open.

Comparison with Allen-Bradley ControlLogix Redundancy

ControlLogix with firmware 19.x and later supports automatic IP address swap on switchover when the EtherNet/IP module is configured with the "IP Address Swapping" option in RSLinx / Studio 5000. The swap is essentially seamless because the EtherNet/IP module on the standby rack takes over the master's IP and the open CIP connections are repointed to the new module without renegotiation.

The architectural difference reflects a deeper protocol choice: EtherNet/IP over UDP-based implicit messaging is more tolerant of endpoint changes than S7 communication over TCP. Siemens' answer is documented and supported; it is simply a different design point.

S7-1500R/H and the System IP Address

For new installations, Siemens has addressed the IP swap problem in the S7-1500R/H redundant system. Starting with STEP 7 V19 (TIA Portal V19), it is possible to assign a system IP address to the W1 virtual interface of an R/H-CPU. The communication partners connect to this single system IP, and the R/H-CPU handles the path selection internally. The system IP is documented in the TIA Portal Help under "System IP addresses for communications processors".

This is the closest Siemens equivalent to Allen-Bradley's IP swap, and it works for S7 communication, PROFINET, and Modbus TCP (with the right CP/CM module). For a new project where the customer insists on a single IP for the redundant controller, the S7-1500R/H with a system IP is the recommended path.

For an existing S7-400H installation, migration is rarely justified solely for IP swap; the four-connection matrix or a SCALANCE NAT gateway is more cost-effective.

Verification and Commissioning Steps

After configuring the four-connection matrix, perform the following verification:

1. With both CPUs in RUN and both CPs online, confirm all four TCP connections from the SCADA show "Established" in the diagnostic buffer.
2. From each CPU, force the SWITCH function (STEP 7 -> PLC -> Operating Mode -> Switch). Confirm the SCADA continues to read tags without dropping more than one poll cycle.
3. Pull the Ethernet cable on CP C. Confirm SCADA fails over to CONN_AD within the configured timeout. Confirm CP C's diagnostic buffer shows "Link down" and the partner sees a TCP RST.
4. Pull the Ethernet cable on CP D. Same verification for the redundant path.
5. Power off rack 0 entirely. Confirm SCADA fails over from CONN_AC/CONN_AD to CONN_BC/CONN_BD.
6. Restore rack 0 and confirm SCADA returns to its preferred CONN_AC / CONN_AD path without operator intervention.
7. Trigger a STOP-RUN on the master CPU. Verify that the standby takes over as master and that the SCADA's tag updates resume.
8. Inspect the CPU's diagnostic buffer for OB70 / OB72 events. OB70 (redundancy loss) should fire when CP C is pulled; OB72 (standby takeover) should fire on rack 0 power loss.

If FB55 is used for any dynamic IP change, also verify:

1. The CP's diagnostic buffer shows "Restart executed by user program" and the new IP becomes active within 15 s.
2. All open connections on the CP are terminated with TCP RST, not TCP FIN, because the CP restarts.
3. FB55 returns status word 0000h on success and a non-zero status (e.g., 8090h) on failure. Status 8090h means "CP not reachable", typically because the LADDR is wrong or the CP is in STOP.

Troubleshooting Matrix

Field-Proven Caveats

• The CP 443-1 EX20 and later support PROFINET IO controller mode in addition to S7 communication. When used as a PROFINET controller on an H-system, the redundancy behavior is governed by PROFINET IO redundancy (AR set), not by IP swap. PROFINET IO devices see a single logical controller; the PROFINET stack handles the failover transparently for cyclic IO data, but not for acyclic record reads that were in flight.
• For S7 communication over TCP, the connection is broken on CP restart but the CPU's CP-recovery logic re-establishes it within 30 s, provided the partner still has the connection in its table.
• Modbus TCP on CP 443-1 (via the "Modbus/TCP CP" option) does not implement session persistence. Each request is independent, so the loss on switchover is limited to in-flight requests; the next poll from the master recovers automatically.
• Some industrial routers (e.g., Hirschmann RS20, Phoenix Contact FL MGUARD) support conditional NAT rules with ICMP-based failover tracking. This is the cleanest software-only solution when the SCADA cannot be modified.
• The four-connection matrix roughly doubles the partner's tag traffic because each tag is read on two connections (primary + verify). On large projects (> 5000 tags) this can saturate the CP's S7 connection bandwidth; use Option 2 (SIMATIC NET multiplexing) instead.
• FB55's LADDR must point to the CP's diagnostic address, not its logical address. Mistaking these returns 8090h even when the CP is reachable.

FAQ