Simulating Siemens S7-300 Software Redundancy with PLCSIM

Overview

Siemens Software Redundancy V1.2 is an option package that turns a pair of S7-300 stations into a hot-standby pair. Each station runs the same user program; the backup CPU takes over the process within the configured switchover time if the master fails. The package is documented in entry ID 21530525 on the Siemens Industry Online Support portal and ships with example projects (including a traffic-light program) located under Start → SIMATIC → S7 Software Redundancy → Examples after installation.

Engineering teams that own only a single physical S7-300 CPU (or no hardware at all) frequently try to validate the redundancy logic against S7-PLCSIM. PLCSIM emulates an S7-300/S7-400 CPU on a PC so that STEP 7 V5.x programs can be loaded, monitored, and forced. The catch is that Software Redundancy is a two-station concept built on a backplane link (MPI, PROFIBUS, or Industrial Ethernet) plus an S7 connection between the two partner CPs. PLCSIM does not fully model that link, so a naive download from STEP 7 leaves the simulated CPU stuck in STOP with diagnostic buffer entries such as "No partner CPU found" or "Redundancy loss".

This reference shows the practical workarounds that allow meaningful pre-hardware testing of the redundancy application code: triggering the redundancy OBs in a single PLCSIM, running two PLCSIM instances side-by-side (S7-PLCSIM V5.4 SP4 and later), and verifying behavior with the bundled traffic-light example.

Prerequisites

Install order matters: STEP 7 first, then S7-PLCSIM, then the Software Redundancy option package. A wrong order is the most common reason for the "FB101 unknown" compile error and for a downloaded CPU that will not leave STOP.

Why the CPU Stays in STOP

When you load the Software Redundancy example onto a single PLCSIM instance, the user program calls FB101 "SWR_ZYK" in OB1. FB101 evaluates the redundancy status word (SWR-Zustandswort) and the partner CPU's reachability on the configured backplane network. With only one PLCSIM active, the partner is permanently unreachable. The library writes a redundancy-loss event to the diagnostic buffer and the CPU enters STOP with one of the following entries:

Open the PLCSIM diagnostic buffer (PLC → Diagnostics → Module Information or CPU → Diagnostic Buffer in STEP 7) to identify which of the four cases applies. The fix depends on the event ID.

Workaround 1 — Triggering the Redundancy OBs in a Single PLCSIM

This is the fastest way to verify that OB70 (I/O redundancy error) and OB72 (CPU redundancy error) execute correctly in your project. You do not need a partner CPU; you simply force the OB to fire.

1. Open STEP 7 with the Software Redundancy example project (e.g. ZLTIMES_1 traffic light).
2. Confirm that OB70 and OB72 exist in the project. If they are missing, insert them via Insert → S7 Block → Organization Block and select the appropriate OB number from the dropdown.
3. Compile and download the entire project to PLCSIM (PLC → Download, or Ctrl+L).
4. Switch PLCSIM to RUN-P via the PLCSIM toolbar (the green RUN/STOP toggle).
5. If the CPU still goes to STOP because of missing partner, open the PLCSIM menu Execute → Trigger Error OB and select OB70 or OB72.
6. Observe the call stack in STEP 7 (online → Monitor/Modify) and the traffic-light outputs (Q 0.0–Q 0.5) changing state as OB70/72 executes the configured behaviour.

Sample OB70 body to confirm OB execution:

// OB70 - I/O Redundancy Error
// Temporary local data available: OB70_FLT_ID (BYTE), OB70_MDL_ADDR (WORD)
L     OB70_MDL_ADDR      // Address of failed I/O
T     MW 100             // Capture for HMI display
SET
SAVE
BE

Sample OB72 body for CPU redundancy error:

// OB72 - CPU Redundancy Error
// Temp locals: OB72_FLT_ID (BYTE), OB72_PRIORITY (BYTE)
L     OB72_FLT_ID
T     MW 102
SET
SAVE
BE

Use Monitor/Modify to view MW100 and MW102 updating each time you re-trigger the error from PLCSIM. This validates that the OBs are present, called, and able to access their input parameters — the core deliverable of the example program.

Workaround 2 — Two PLCSIM Instances on One PC

S7-PLCSIM V5.4 SP4 introduced the ability to launch more than one PLCSIM window simultaneously, each on a separate MPI/TCP address. With two PLCSIM instances you can approximate the master/backup pair, complete with an S7 connection between them, and exercise the full FB101 startup sequence.

1. Install the Service Pack: S7-PLCSIM V5.4 SP4 download & release notes. Restart Windows after install.
2. Launch the first PLCSIM instance from Start → SIMATIC → S7-PLCSIM V5.4 → S7-PLCSIM.
3. In STEP 7, open the Set PG/PC Interface dialog and point it to S7ONLINE → PLCSIM.PROFIBUS.1 for the first instance.
4. Open a second PLCSIM instance. From Start → Run use "C:\Program Files\Siemens\Automation\S7-PLCSIM\S7Wsvapx.exe" -n PLCSIM2 to start a named second instance, or simply launch the executable twice — SP4 supports parallel windows.
5. Configure the NetPro S7 connection between the two stations on PROFIBUS (default) or Industrial Ethernet. Use the CP from the example (e.g. CP 343-1 Lean) on both stations.
6. Load station A (master) into PLCSIM instance 1 and station B (backup) into PLCSIM instance 2. Use PLC → Download with the correct PG/PC interface for each instance.
7. Set both PLCSIM windows to RUN-P. Observe that FB101 reports REDUN_STATUS = 0x0004 (both CPUs available, master active).
8. To simulate failover: stop instance 1 (the master). Within ≤ 100 ms (configurable, default 100 ms) instance 2 takes over; the traffic light outputs continue without visible interruption.

Workaround 3 — MPI/DP Coupling with Two Real PLCSIM Channels

If you cannot get two PLCSIM windows to bind to the same PROFIBUS channel, switch both PLCSIM instances to TCP/IP addressing via PLCSIM → Set PG Interface → PLCSIM.TCPIP.1. STEP 7 NetPro can be set up with an S7 connection over ISO-on-TCP between two virtual stations, and PLCSIM will route it through the local TCP stack. This is the most reliable two-instance configuration on Windows 10.

Step-by-Step: Traffic-Light Example Walk-Through

The traffic-light program in ZLTIMES_1 is a 6-output sequence (red/amber/green × two directions) used to demonstrate that OB70 and OB72 do not freeze the time-driven lights when a redundancy event occurs. To reproduce the verification in PLCSIM:

1. Open the example project in STEP 7 V5.x and assign the example CPU (e.g. CPU 316-2 DP).
2. In HW Config, set the CP 343-1 (or CP 342-5) and configure the Ethernet/PROFIBUS subnet that the redundancy S7 connection will use.
3. Open NetPro and verify the S7 connection from station A → B and from station B → A is configured with Active connection establishment = yes on both sides.
4. Compile and save. In the symbol table, confirm I/O symbols:
   Q 0.0 = Light_A_Red, Q 0.1 = Light_A_Amber, Q 0.2 = Light_A_Green, Q 0.3 = Light_B_Red, Q 0.4 = Light_B_Amber, Q 0.5 = Light_B_Green.
5. Download to PLCSIM (single-instance path) or to two PLCSIM instances (dual path).
6. Set OB1 scan time to 100 ms (CPU Properties → Cycle/Clock Memory). The traffic-light sequencer uses timer T1/T2 in OB1.
7. Run. Lights cycle: A green / B red → A amber / B red → A red / B red → A red / B green → A red / B amber → A red / B red → loop.
8. Trigger OB70 from PLCSIM. The sequence must continue; OB70 returns immediately and does not block OB1.
9. Trigger OB72 from PLCSIM. Same result; OB72 should not stop the sequencer.

Pass criteria: the lights keep cycling through at least 3 full sequences (about 15–30 s) while OB70/72 are repeatedly triggered. If the cycle stalls, the OB is missing or the call to FB101 inside OB72 is blocking.

Specifications and Limits of PLCSIM Redundancy Testing

Troubleshooting Matrix

Verification Procedure

After each workaround, perform these three checks to confirm the simulation is doing what you expect:

1. Diagnostic buffer is clean. Open CPU → Diagnostic Buffer in STEP 7 (online). With redundancy running correctly, no 0xE2xx events should appear except for the one you deliberately triggered.
2. FB101 status word is sane. In Monitor/Modify, force display of DB_W.SWR_ZUSTW. The value should be 0x0004 (master, partner available) or 0x0001 (backup) — never 0x8000 (initial) once the program has run for a few cycles.
3. Process I/O continues during a fault OB. Watch the six traffic-light outputs in a VAT table. While OB70 or OB72 is being executed (visible by the call stack), outputs should continue to update. If they freeze, OB70/72 is blocking — refactor.

Notes on Real Hardware Commissioning

PLCSIM validation is only a pre-check. When you move the same program to two physical S7-300 stations:

• Use identical CPU firmware versions on both partners; mismatched firmware is the leading cause of mysterious "redundancy loss" events in the field.
• Configure the S7 connection with Active connection establishment = yes on station 0 (the master candidate) and no on station 1 (the backup). This avoids both stations fighting to be master at startup.
• Set the S7 connection's Watchdog to a value compatible with the configured switchover time. Default 100 ms; raise to 500 ms for slower PROFIBUS segments.
• Load OB70 and OB72 with real-world logic: record the event ID and timestamp, set a status bit for the HMI, do not include any blocking calls.
• Test failover by physically pulling the PROFIBUS connector on the master and verifying the backup takes over within the configured window.

For S7-400 H-systems (CPU 41x-H), Software Redundancy is not used — the H-system firmware provides the redundancy natively, and PLCSIM does not support H-system simulation at all. For those platforms you must commission on real hardware.