S7-400H Standby CPU Stop: Resolving CONNECT Refusal Fault

1. Problem Overview

On Siemens S7-400H high-availability systems, one of the most disruptive commissioning and runtime events is the diagnostic message:

Standby CPU Link up/update by Master CPU aborted.
Cause: Refusal of CONNECT due to different structure of the part AS

This message is raised by the standby CPU's operating system when the master CPU attempts to establish the redundancy link (LINK_UP / UPDATE phase) and the standby rejects the connect request because its internal "structure" — the image of hardware, firmware, user program, and memory card content — does not match the master's.

The standby CPU then transitions to STOP with diagnostic buffer entry class OB70 / OB72 / OB80 / OB100 family, and the H-system continues to run in Solo mode. The process is no longer redundant: a single master CPU failure is now a full plant trip.

The error class in the diagnostic buffer is typically reported under Event ID range 0x39xx for H-system redundancy (for example 0x3901, 0x3902, 0x3903), and the S7-400H system manual and STEP 7 online help categorize them under Redundancy events / H-CPU structure comparison.

2. Root Cause: What "Different Structure of the Part AS" Means

The H-system compares a structure fingerprint between the two CPUs during link-up. The fingerprint is a composite of:

1. Hardware configuration – rack layout, slot population, signal modules, IM module count and order.
2. Firmware version – exact firmware release of each CPU, including hot-fix level.
3. Memory card (MMC) type and content – Flash card size, partition table, and the user program image stored on it.
4. User program – blocks, OB, FB, FC, DB identifiers and contents; system data blocks (SDB).
5. Sync module pair – module type, firmware version, and slot assignment (modules 1 and 2 on each CPU must match in type).
6. CPU operating mode parameters – H-parameter set in HW Config (monitoring time, test cycle, etc.).

If any of these differs, the standby's redundancy OS rejects CONNECT. The most common field cause — confirmed in the source case — is a mismatched memory card: one CPU carries an MMC of one size / type / generation while the other carries a different one, even if both were loaded with the same project at some prior moment.

3. Required Tools and Prerequisites

Before opening the cabinet, gather the following:

• STEP 7 V5.5 SPx or TIA Portal V16+ (matching the project version) with the S7-400H HSP installed.
• Ethernet / MPI programming cable (or PROFIBUS CP for legacy CP 443-1 paths).
• Matched pair of Sync modules (Siemens 6ES7 960-1AA0x family for short-distance FO, or 6ES7 960-1AB0x for long-distance FO) of identical MLFB and firmware.
• Identical S7-400 Flash cards (MMC) for the CPU type in use, e.g.:
  • 6ES7 952-1AS00-0AA0 – 8 MB Flash
  • 6ES7 952-1AY00-0AA0 – 32 MB Flash
  • 6ES7 952-1AK00-0AA0 – 256 KB Flash
• Matched pair of H-CPUs of identical MLFB and identical firmware release (for example 6ES7 417-4HT14-0AB0 FW V6.0.7 on both sides).
• FO patch cables of the correct length class (short-distance 6ES7 960-1AA04 module → max 10 m; long-distance 6ES7 960-1AB04 → up to 10 km with multimode fiber).

4. Diagnostic Entry Points in STEP 7

Use the following sequence in STEP 7 (V5.5 or TIA equivalent) to localize the mismatch before opening the rack door:

1. Open the project, go Online → Accessible Nodes and identify both CPUs (Rack 0 and Rack 1) by their IP / MPI addresses.
2. Open PLC → Module Information for each CPU and inspect:
   • Diagnostic buffer – locate the most recent H-system event with Event ID 0x3901–0x3940.
   • Memory tab – confirm Flash card type and free / used memory on each side.
   • Performance → Operating mode – confirm master reports "RUN (redundant)" while standby reports "STOP (caused by redundancy)".
   • Firmware – record version string for both CPUs.
3. Open HW Config, right-click each CPU and select Object Properties → Redundancy. Compare monitoring times, test cycles, and the configured sync module pair.
4. From HW Config, run Station → Compare on the online rack against the offline project to surface SDB / module differences.

The diagnostic buffer entry typically reads:

Event ID    : 0x3902
OB          : OB 70 (redundancy loss)
Date/Time   : yyyy-mm-dd hh:mm:ss.sss
Source      : Standby CPU
Description : LINK_UP aborted - Refusal of CONNECT
              different structure of part AS
              expected <SDB-id>, received <SDB-id>

The "expected / received" SDB identifier is a strong tell: it points to either the HW configuration SDB (SDB 1000–1111 range) or the user-program SDB container (SDB 0–999) on the Flash card.

5. Step-by-Step Resolution Procedure

5.1 Mismatched memory card (the source case)

1. Power down the standby CPU only. The master keeps running in Solo mode.
2. Remove the Flash card from the standby CPU.
3. Compare the label of the removed card against the master-side card. Note MLFB, capacity, and Siemens date code.
4. Insert a Flash card that matches the master-side card exactly (same MLFB, same capacity, same generation).
5. Power up the standby CPU.
6. From STEP 7, go Online → Download to Device with target = standby CPU only. Confirm the Flash card write completes without error.
7. Observe the SF / RUN / REDF / IFM LEDs on both CPUs. The standby should clear REDF and transition through LINK_UP → UPDATE → REDUNDANT within the configured sync time (default 500 ms).
8. Verify in Module Information that both CPUs report operating mode RUN (redundant).

5.2 Mismatched firmware version

1. Determine the desired firmware version from the STEP 7 project or the offline backup. Use SIMATIC Manager → PLC → Update Firmware (or for newer CPUs, the Web server firmware update path).
2. Update the lower-firmware CPU first. Do not interrupt power during the update; on a CPU 41x-H, a failed firmware update can leave the MMC unbootable.
3. After the first CPU returns to RUN, perform a memory reset (MRES) and re-download the project.
4. Repeat the update on the second CPU to bring it to identical firmware.
5. Re-attempt link-up.

5.3 Mismatched sync module

1. Identify sync module MLFB on both sides. Acceptable pairings:
   • 6ES7 960-1AA04-0XA0 on both sides (10 m FO)
   • 6ES7 960-1AB04-0XA0 on both sides (10 km FO)
   Mixing AA04 with AB04 is not permitted even though they use the same physical port — the optical budget differs and the link check fails before the structure check ever runs.
2. Replace the out-of-spec module with one that matches its partner.
3. Replace both FO patch cables with matched length and grade cables (multi-mode 50/125 µm or 62.5/125 µm graded-index for short-distance; single-mode 9/125 µm for long-distance).
4. Bring the standby CPU back online and monitor the IFM1 / IFM2 LEDs on each synch module. Both must show steady green.

5.4 Mismatched HW Config (SDB container)

1. Open HW Config and select the offline project.
2. Re-run Station → Consistency Check and Compile and Download Objects.
3. Download hardware configuration to both CPUs in succession: master first, then standby. After the standby download, the system performs a forced LINK_UP.
4. Verify both CPUs now report identical rack fingerprint in Module Information → Communication → Redundancy.

6. Verification and Commissioning Tests

Once the standby returns to RUN-redundant, execute the standard H-system acceptance test sequence:

1. Monitor mode test – Place standby into RUN-STOP-RUN cycle via STEP 7 and confirm UPDATE completes without buffer events.
2. Master power-down test – Briefly remove 24 V power to the master rack. The standby must take over within < 100 ms and the process must not see a CPU-fault OB70 trigger on any I/O module. Restore power; the new master must re-synchronize without intervention.
3. Hot-sync test – Cycle power to one sync module pair only. The remaining pair must keep redundancy alive (single-pair survivable). The system must not enter Solo mode.
4. Firmware / SDB compare – Run Station → Compare Online/Offline for both racks and confirm no differences.

7. Related S7-400H Diagnostic Events

Several events share the same root-cause family as Refusal of CONNECT. Review the diagnostic buffer for any of the following when triaging a similar case:

8. Preventive Maintenance Checklist

For every H-system handed over to operations, the engineering team should produce a Redundancy Spare Card with the following frozen specification:

• CPU MLFB and firmware release locked at handover.
• Flash card MLFB, capacity, and Siemens date code recorded per CPU.
• Sync module MLFB and firmware release locked.
• FO cable length and fiber type (50/125 µm vs 9/125 µm) recorded per channel.
• Two spare flash cards pre-imaged with the production project stored in a sealed ESD bag in the cabinet.
• Any change to the spare-card list requires a documented hot-cutover test, not a same-day swap without test.

Track firmware drift: even minor Siemens service packs (V6.0.5 → V6.0.7) can change the structure fingerprint. Schedule firmware upgrades so both sides are updated in the same maintenance window.

9. Common Pitfalls

1. Re-downloading only the standby after an HW change – this creates the mismatch in the first place. Always download to master and standby in the same online session, or re-download both after any SDB change.
2. Mixing RAM and Flash cards – S7-400H only supports Flash cards (MMC). RAM cards are rejected structurally even if the project appears to load.
3. Different STEP 7 / TIA project versions – a project edited in TIA V17 and re-saved will have a different SDB layout from one last edited in TIA V16. Re-load to both sides from the same export.
4. Replacing only one CPU after a failure – Siemens supply of spare CPUs may include an older firmware release. Always upgrade the spare before installing.
5. Forgetting to clear REDF – after the underlying cause is fixed, the redundancy LED may still show REDF. A power cycle or explicit Stop → Run on the standby is required.

10. When the Fault Persists

If the standby still refuses CONNECT after memory cards, firmware, sync modules, and HW Config have all been verified equal:

1. Run a Memory Reset (MRES) on both CPUs.
2. Build a minimal test project containing one cyclic OB1 and one DB. Download to both CPUs without any memory card installed (load into RAM only).
3. Attempt redundancy. If both CPUs now enter RUN-redundant, the original project itself is the structure mismatch — likely a corrupted SDB. Re-export the project from the engineering backup and re-load.
4. Swap the physical sync modules between the two racks. If the standby that was in Rack 0 now links up while Rack 1 stops, the original sync module in Rack 1 was the source of the corruption (less common but documented).
5. As a last resort, replace both sync modules and both FO cables with new, matched units.