Connecting Third-Party HMI to Siemens S7-400H Redundant CPU

1. System Overview

An S7-400H redundant automation system consists of two CPU 41x-5H processors running in parallel, each backed by its own synchronisation module pair and linked through redundant PROFINET or PROFIBUS networks. Both CPUs execute the same user program in lock-step; one operates as the master while the other remains in standby. The standby CPU takes over control within milliseconds if the master fails, which is why a third-party HMI must be configured to follow the active master rather than binding to a single CPU IP address.

When the HMI is a Schneider Electric Magelis PC Panel running Vijeo Designer, EcoStruxure Operator Terminal Expert, or any OPC DA/UA client, the integration relies entirely on standard S7 communication over TCP/IP. No proprietary Siemens HMI protocol is required, but the HMI application must implement its own master/standby detection and connection failover because Schneider HMI drivers do not interpret the Siemens H redundancy state automatically.

This reference covers the topology, hardware list, IP planning, PLC programming (H_STATUS block and SFC51 polling), lifebit handling, HMI-side failover logic, and verification procedure for an S7-400H ↔ third-party HMI link. Notes on S7-1500R/H migration are included for projects that have moved to the newer redundant platform.

2. Prerequisites

3. Network Topology

Two physically separated Ethernet networks are recommended for a redundant HMI link. Network A terminates on the integrated PROFINET interface of CPU 0 (or on CP 443-1 installed in the CPU 0 rack); Network B terminates on CPU 1. The HMI PC Panel hosts two NICs and connects to both networks. If a single network is used, the HMI must poll both CPU IPs and switch the active connection when the master changes.

The diagram above illustrates the dual-CP topology with a Schneider HMI on two independent Ethernet segments. If a single switch is preferred, both CP 443-1 modules must be addressed through separate subnets or the HMI must manage a primary/secondary driver pair that toggles on master/standby state.

4. IP Address Planning

5. Step-by-Step Configuration

5.1 Hardware Installation

1. Insert both CPU 41x-5H modules into the UR2-H rack (or two separate racks connected via the H sync cable). Verify the order slot of each CPU matches the H configuration in STEP 7.
2. Install one CP 443-1 in each rack. Note that the CP slots are CPU-local; the S7-400H does not share CPs across CPUs.
3. Connect the fibre-optic sync cables between the two sync module sub-slots and verify the SYNC LED on both CPUs is solid green.
4. Connect the Ethernet cables from each CP 443-1 to the appropriate managed switch.
5. Connect the Schneider HMI to both switches (or to a single switch if both CPs are on the same subnet and IP-level failover is acceptable).

5.2 STEP 7 Project Setup

1. Open STEP 7 V5.6 and create a new S7-400H station. Add both CPU 41x-5H modules and both CP 443-1 modules to the hardware configuration.
2. Configure the Ethernet interface of each CP 443-1 with the IPs from the planning table. Enable "Use the router" only if your network requires it.
3. In NetPro, add a TCP/IP connection from the HMI to CPU 0 (one connection object) and a second connection from the HMI to CPU 1. The HMI driver will instantiate both; only one is active at a time.
4. Set the connection type to "S7 connection" with the partner being the CPU's PROFINET interface IP, not the CP. The CP simply routes the S7 frames.
5. Download the hardware configuration to both CPUs and verify online that both CPs are reachable from the engineering station (ping or "Accessible Nodes" in STEP 7).

5.3 H_STATUS Block Integration

Siemens publishes a free, ready-to-use block that polls the H system status via SFC51 and writes the results to a data block. Download the block from Siemens support entry 19537149 and integrate it into your STEP 7 project.

The block exposes the following outputs (refer to the block documentation shipped with the download for the exact DB layout, as it changes between block revisions):

Call H_STATUS in OB1 (or in a cyclic OB35 at 100 ms) on both CPUs. Only the master will update the LIFEBIT and MASTER_CPU; the standby CPU returns LIFEBIT frozen. The HMI reads the DB from either CPU and uses the LIFEBIT delta to determine which CPU is currently authoritative.

5.4 Lifebit Programming

The lifebit is the most reliable mechanism to detect a CPU that has entered STOP mode. SSL state reads may freeze at the last valid value, so a changing counter is essential for correct failover.

Sample STL implementation (to be added inside H_STATUS or in a complementary block):

// Increment lifebit each cycle on master only
A     "H_STATE_MASTER"   // H_STATUS output
JCN   NOUP
L     "HMI_LIFEBIT".DBD0 // DWORD counter in shared DB
+     1
T     "HMI_LIFEBIT".DBD0
NOUP: NOP 0

Place the lifebit in a DB that is part of the S7 connection data viewable by the HMI. The HMI should sample the lifebit every 1–2 seconds; if the value does not change for more than 5 seconds, the current master is considered stopped and the HMI switches its active connection to the standby CPU.

5.5 HMI Configuration (Schneider Magelis / Vijeo Designer)

1. Install the Schneider S7 driver (Siemens S7 MPI/TCP-IP) in Vijeo Designer or the equivalent driver in EcoStruxure Operator Terminal Expert.
2. Create two driver instances, one pointing to 192.168.10.10 (CPU 0) and one pointing to 192.168.10.20 (CPU 1). Set the rack/slot to 0/3 for the integrated PROFINET interface (or to the CP slot if going through the CP).
3. Bind every HMI tag to both driver instances, so the variable is read from either CPU. Vijeo Designer supports variable aliasing and "primary/secondary" driver failover natively; in EOTE, this is handled in the variable's "Quality" properties.
4. Add a script (Vijeo Designer's VBA or EOTE's C# / VB.net script) that polls the H_STATUS DB on both CPUs. The script should:
   • Read MASTER_CPU and LIFEBIT from the active driver.
   • If MASTER_CPU is FALSE and LIFEBIT is frozen for more than 5 s, switch the primary driver to the standby connection.
   • Re-evaluate every 2 s.
5. Display a banner ("Connected to CPU 0 / CPU 1") on every screen so the operator can verify the active connection manually.

6. Redundancy State Detection via SSL IDs

The SFC51 "RDSYSST" function is the lowest-level mechanism to read system state lists. For a deeper understanding of the underlying data, the H_STATUS block internally calls SFC51 with the following SSL_IDs (the exact list depends on the CPU firmware; refer to the S7-400H System Manual and the H_STATUS block documentation for the version you use):

Direct SFC51 usage (in STL) for reading the H state:

CALL "RDSYSST"  // SFC51
REQ     := TRUE
RET_VAL := MW100
BUSY    := M101.0
SSL_ID  := W#16#0092
INDEX   := W#16#0000
SSL_ADDR:= P#DB20.DBX0.0 BYTE 32

For third-party HMI integration, it is strongly recommended to use the H_STATUS block rather than calling SFC51 directly, because the SSL data layout varies across firmware versions and a single DB change can break the HMI polling logic without any error indication at the HMI side.

7. HMI-Side Failover Logic

The HMI must implement a state machine that follows the master. A minimal implementation in pseudocode (translatable to Vijeo Designer VBA, EOTE C#, or any OPC client):

// Run every 2 seconds
function UpdateActiveConnection():
    active_master  = ReadTag("HMI_DB.H_STATE_MASTER")
    active_lifebit = ReadTag("HMI_DB.HMI_LIFEBIT")
    active_quality = GetTagQuality("HMI_DB.H_STATE_MASTER")
    active_age     = (now - last_lifebit_time)

    if active_quality == BAD and now - last_failover > 30:
        // Driver connection is broken; switch immediately
        SetPrimaryDriver("CPU_1_DRIVER")
        ShowBanner("Failover: connected to CPU 1")
        last_failover = now
        return

    if active_master == FALSE and active_age > 5000:
        // Master appears down; switch to standby
        SetPrimaryDriver("CPU_1_DRIVER")
        ShowBanner("Failover: connected to CPU 1")
        last_failover = now
        return

    if last_lifebit_value != active_lifebit:
        last_lifebit_value = active_lifebit
        last_lifebit_time  = now

Place the script in the HMI's main loop (Vijeo: Project > Scripts > Project Script; EOTE: Screen / Project scripting). Bind variable access through the driver so the script sees quality codes — if the connection is broken, the driver returns a "bad" quality and the script triggers an immediate failover without waiting for the lifebit timeout.

8. Verification and Commissioning

1. Power-up test: Power both CPUs. Verify SYNC LEDs go solid green within 30 s. From the HMI, confirm that the H_STATE_MASTER tag from CPU 0 returns TRUE and from CPU 1 returns FALSE.
2. Single-CPU stop test: With the system redundant, set CPU 0 to STOP via STEP 7 (online > STOP). Within 2 s, CPU 1 must take over and the HMI must switch its active driver to the CPU 1 connection. Verify the operator banner updates accordingly.
3. Cable fault test: Disconnect the Ethernet cable between CP 443-1 of CPU 0 and Switch A. CPU 1 must remain master (if it was already master) or take over. The HMI must not lose its connection permanently if the active CP link is down and the standby CP is up.
4. Sync fault test: Disconnect the fibre-optic sync cable. Both CPUs should fault (SF LED on); after the configured link-down time, the master should remain master and the standby should switch to STOP-with-sync-error. Restore the cable and verify resync without manual intervention.
5. Lifebit test: With the HMI connected, observe the LIFEBIT tag in a watch window. It must increment at least once per second on the master. Now set the master to STOP. The LIFEBIT must freeze and the HMI must switch to the standby within 5 s.
6. Tag round-trip: Toggle a boolean tag from the HMI and confirm the change appears in the PLC on the currently active CPU. Repeat for both CPU roles.
7. Quality-code test: Pull the active Ethernet cable while the HMI is running. The driver should report a "bad" quality within the configured timeout (default 3–5 s), and the failover script should switch to the standby CPU before the lifebit timer expires.
8. Sustained redundancy test: Run the system for at least 24 h with both CPUs online. Verify that LIFEBIT and MASTER_CPU do not flicker, that the HMI banner does not change spuriously, and that there are no S7 connection re-establishment events in the HMI log.

9. S7-1500R/H Considerations

Newer projects may run on S7-1500R (without H sync module) or S7-1500H (with H sync module). The redundancy philosophy is the same, but several details differ:

• PROFINET is the only supported fieldbus. PROFIBUS is not available on S7-1500R/H CPUs.
• Both PROFINET interfaces of the CPU are used for the H ring; an external CP is not required unless you need additional isolated networks.
• If the HMI is placed inside the PROFINET ring with S7-1500R, the HMI must support media redundancy (MRP client, IEC 62439-2). The H-Sync forwarding function is also recommended, as described in the S7-1500R/H application planning documentation.
• Connection to HMI panels is described in the Siemens application document "Connecting a SIMATIC HMI Panel with a SIMATIC S7-1500R/H". Although the document covers Siemens panels, the same principles apply to third-party HMIs over standard S7 communication.
• The H_STATUS block in STEP 7 V5.x is not directly compatible with S7-1500R/H. Use the redundancy status functions available in the S7-1500R/H CPU firmware (block "GetRedundancyState" or read the "RHINFO" structure) and provide the equivalent data to the HMI via a shared DB.
• TIA Portal V17 or V18 is required to engineer the S7-1500R/H station; STEP 7 V5.6 cannot program an S7-1500 CPU.

10. Troubleshooting Matrix

11. Frequently Asked Questions