WinLC Redundancy: OPC-Based Hot-Standby for S7 Soft PLC

PC-based soft PLCs such as Siemens SIMATIC WinLC collapse traditional PLC hardware reliability into a single Windows process. In non-time-critical applications — brewing lines, water treatment, batching, building services — engineers often accept minutes of downtime in exchange for dramatically lower hardware cost, but they still need a documented path back to a running control system after a primary PC failure. This reference documents an OPC-based hot-standby topology for WinLC with a 10-minute-class manual failover target: two PC stations running identical WinLC projects, exchanging state through OPC, and a documented procedure for switching the PROFIBUS master to the standby PC.

1. WinLC Architecture and Failure Modes

WinLC is the soft-PLC member of the SIMATIC WinAC family. The currently shipping variant, WinAC RTX 2010 (and its successors integrated into TIA Portal as WinAC RTX / WinAC RTX F), executes the S7-300 / S7-400 instruction set as a Windows process paired with a real-time extension (IntervalZero RTX or RTX64). A separate WinAC Slot variant (Type PC plug-in card) and the legacy WinLC without RTX targeted the standard Windows scheduler and remain common in installed bases even though they are no longer in active marketing.

Regardless of variant, every WinLC deployment concentrates all control logic into a single Windows process that owns a PROFIBUS Class 1 master interface. When that process stops, control stops. Failures fall into the following modes:

For a brewing application with three active batches, the relevant failure modes are the first three plus the network partition. The hot-standby pair must detect any of them within the user's tolerance window (10 minutes in the typical requirement) and bring the secondary up as the new master without corrupting in-flight batches.

2. Redundancy Topologies for Soft PLC

PC-pair redundancy for WinLC is rarely documented in vendor literature because it falls outside the certified WinAC RTX F and S7-400H offerings. Engineers typically choose between four topologies:

The 10-minute acceptable downtime maps cleanly to the warm standby topology: the secondary WinLC runs continuously in a passive mode, reads process values through OPC, and is ready to take over the PROFIBUS master role after a manual switch. The primary does not require any vendor "redundancy" license because no licensed second-master relationship exists at the PROFIBUS layer.

A hot-standby (parallel execution) topology is not viable on WinLC because PROFIBUS-DP allows exactly one Class 1 master per segment. Two parallel WinLCs cannot both own the bus; any attempt to do so produces bus collisions that look like random slave faults.

3. PROFIBUS Master Switching Constraints

The most common misconception in PC-pair redundancy is that "the second PC does not qualify as a second PROFIBUS master" simply because it is silent on the bus. From the perspective of a PROFIBUS-DP slave, a silent master is indistinguishable from a working master until the slave's watchdog timer expires. Once it expires, the slave enters its configured fallback state (typically outputs off, as defined in the GSD file's parameter assignment).

Concrete constraints govern the failover design:

• GSD file identity. Both WinLC projects must reference the same PROFIBUS GSD files for every slave. A mismatch in the slave's parameterization message (Set_Slave_Param) will be detected by the slave and reported as a configuration fault.
• Bus address reservation. PROFIBUS reserves the address of the silent master. Before the secondary can take over, the primary must release the bus, either by WinLC shutdown or by physically disconnecting its PROFIBUS interface (CP 5611 / CP 5613 / CP 5621).
• Slaves do not auto-reconfigure. When the secondary starts as master, every slave performs a fresh parameterization check. Parameterization messages from the secondary must match byte-for-byte what the primary was sending. Maintain a single canonical STEP 7 / TIA Portal source for both WinLC stations.
• DP cycle time. The slave watchdog is set to a multiple of the master's configured DP cycle time. Default TIA Portal values place the watchdog at 3-10 seconds. After the failover, the secondary must reach OPERATE state within the watchdog window or slaves will fault.
• Diagnostic buffer. PROFIBUS diagnostics are written to the master's diagnostic buffer. After a switch, the secondary's buffer starts empty — for post-incident analysis, save the primary's diagnostic buffer (if accessible) via PG functions before the PC is powered down.
• DP-V0 vs DP-V1/V2. Slaves using DP-V1 acyclic services (e.g. ET200S with diagnostic data records) require the secondary to support the same DP-V1 features. Verify in HW Config that the same DP version is enabled on both WinLC projects.
• Bus topology termination. The PROFIBUS segment requires termination at both ends. Swapping the master CP without re-terminating the segment will produce reflection faults on long cables (> 10 m). Use a DP/DP coupler or a PROFIBUS repeater to keep termination topology stable across master swaps.

4. OPC-Based State Synchronization

OPC is the only data path that survives a WinLC crash and works between two independent PCs without custom socket code. The pairing of SIMATIC NET PC Software as the OPC server on each WinLC station and SIMATIC NET Configuration Console as the configuration tool is documented in the SIMATIC NET manual collection on the Siemens Industry Online Support portal at support.industry.siemens.com.

OPC DA vs OPC UA for WinLC

Two OPC profiles are usable with current SIMATIC NET releases:

• OPC DA 3.0 — Microsoft COM/DCOM based, supported by every WinAC variant including legacy WinLC. Mature tooling, but DCOM configuration is non-trivial across workgroups and blocked by many corporate firewalls. Default for installed bases.
• OPC UA — TCP based, supported by SIMATIC NET V14 SP1 and later. Easier firewall traversal, native information modeling, certificate-based security. Recommended for new deployments and any network crossing a router boundary.

For a two-PC pair on the same VLAN with OPC DA, the configuration is shorter and the tag space is well understood. For any deployment that crosses a router or a Windows domain boundary, switch to OPC UA.

State Synchronization Pattern

The state to be mirrored from primary to secondary falls into three categories:

1. Persistent recipe data. Stored in a designated DB (e.g. DB 900 "Recipes"). Snapshot every N seconds, write to OPC tag group Recipe.*.
2. Runtime batch state. Current batch ID, step number, timers, setpoints. Stored in DB 901 "BatchState". Snapshot every cycle (250 ms - 1 s) or on change.
3. Process I/O mirror. Live analog inputs and digital inputs from primary. Published as PI.* and DI.* so secondary can display the process without owning the PROFIBUS.

The secondary WinLC reads these tags via an OPC client subscription (SIMATIC NET OPC Scout or a custom VB/C# client) and writes them into its local DB 902 "ShadowState". On failover, the secondary's batch code reads DB 902 first and continues from the last consistent snapshot.

5. SIMATIC NET Configuration Console: Building the S7 Connection

The SIMATIC NET Configuration Console ships with every SIMATIC NET PC Software DVD. It is the only supported way to create S7 connections and bind them to OPC server instances. Below is the minimum configuration for a peer-to-peer S7 connection between two WinLC stations.

1. Install SIMATIC NET PC Software on both PCs. Use a release that matches the WinAC RTX version (e.g. SIMATIC NET V14 for WinAC RTX 2010, SIMATIC NET V18 for WinAC RTX under TIA Portal V18).
2. Open Configuration Console (Start → SIMATIC → SIMATIC NET → Configuration Console).
3. Select Modules and verify the OPC server module and the S7 protocol module are loaded. If a yellow triangle appears, the module needs a manual start via the s7oscon configuration entry.
4. Right-click PC Station → Add → S7 Connection. Choose ISO-on-TCP as the transport. ISO-on-TCP (RFC1006, port 102) is the default and is what WinLC speaks natively. Plain TCP is supported but loses the partner addressing flexibility of TSAPs.
5. Enter the partner IP address, partner rack, partner slot. For WinAC RTX the slot is typically 2 (the default WinAC RTX slot in STEP 7 / TIA Portal).
6. Set the local TSAP to 01.01 and the remote TSAP to 01.02 for the partner direction. TSAP pairs must be reversed on the partner's Configuration Console. The first octet is the connection type (01 = S7 connection), the second is the rack.slot.
7. Set connection ID to a unique value (1 and 2 are common). This is the ID you will reference from the OPC client.
8. Click Apply and Download to push the configuration to the running OPC server. The PC Station icon in the Configuration Console should turn green within 10 seconds.
9. Test connectivity with OPC Scout V10. Insert an item, browse the partner DB 1 area, and verify live values.

Common S7 connection error codes from the OPC server log:

6. Heartbeat and Liveness Detection

Detection latency sets the floor on failover time. The recommended pattern is a bidirectional heartbeat on a fast OB:

On the primary (WinLC OB35, 100 ms cyclic interrupt):

// S7-ST on WinAC RTX, OB35
// Increment heartbeat counter and publish to OPC
      L     MB    100          // heartbeat counter
      +     1
      T     MB    100
// Write MB100 into DB 903 byte 0 for OPC exposure
      L     MB    100
      T     DBB    0           // DB903.DBB0 = heartbeat
// Set flag "PrimaryHealthy" if OB1 is running
      U     M      10.0         // OB1 running bit (auto-set by WinLC)
      =     M      10.1         // PrimaryHealthy

On the secondary, a separate OB35 watches for the primary's heartbeat via OPC subscription into MW200:

// Secondary WinLC, OB35
// MW200 = last seen heartbeat, MW202 = current seen heartbeat
      L     MW    200
      L     MW    202
      <>I
      JC    Upd                 // on change, reset staleness timer
// No change: increment staleness seconds counter
      L     MW    204           // staleness in 100ms ticks
      +     1
      T     MW    204
// Compare against 5 second threshold (50 ticks * 100ms = 5000ms)
      L     MW    204
      L     50
      >I
      S     M      20.0         // PrimarySuspect flag
      JU    End
Upd:  L     MW    202
      T     MW    200           // update last seen
      L     0
      T     MW    204           // reset staleness
      R     M      20.0         // clear PrimarySuspect
End:  NOP   0

A 5-second heartbeat timeout is a pragmatic choice: longer than the longest expected WinLC OB1 cycle (typically 50-200 ms), shorter than the user's 10-minute downtime budget by a wide margin. Tune the timeout by capturing the worst-case WinLC cycle time during commissioning; values above 50 ticks indicate a WinLC scan time problem that should be fixed independently of the redundancy design.

7. Hot-Standby Pair Implementation

The PC-pair has three logical roles:

• PC-A (Primary) — owns the PROFIBUS, runs WinLC in normal mode, publishes OPC tags.
• PC-B (Secondary) — runs WinLC in "monitor mode" (no PROFIBUS master active), subscribes to PC-A's OPC tags, maintains shadow DB 902.
• Manual switch — physical PROFIBUS cable swap from PC-A to PC-B (or a DP/DP coupler between the two CPs), then WinLC restart on PC-B in "primary mode".

DB Layout for Shadow State

On startup, the secondary reads DB 902 and reconstructs batch step, elapsed timers, and current setpoints. Any output that was latched "on" by the batch sequence must be reset by the operator's "Resume Batch" confirmation before the secondary writes to outputs, to avoid firing actuators that the primary was about to turn off.

8. Manual Failover Procedure

Document this as a printed checklist and tape it to both PCs. With a 10-minute target, a poorly executed manual failover is the most common cause of extended outages.

1. Confirm primary failure. Ping PC-A. Check WinLC window. Check OPC Scout on PC-B for tag quality. If PC-A is alive but WinLC is hung, attempt remote shutdown via Windows RDP before proceeding.
2. Stop primary WinLC cleanly. If reachable, send the WinLC stop command via RDP. If unreachable, pull the PROFIBUS connector from PC-A's CP first; this releases the bus deterministically.
3. Move PROFIBUS connector. Disconnect the PROFIBUS cable from PC-A's CP 5611/5613/5621 and plug into the corresponding CP on PC-B. If a DP/DP coupler is installed, switch the coupler's master selector.
4. Start secondary WinLC in primary mode. On PC-B, set DB 904 byte 0 to B#16#01 via the WinLC control panel or by toggling the corresponding tag in the project. Restart WinLC. Slaves should reach OPERATE within 3-10 seconds (one watchdog interval).
5. Verify slave states. In WinLC's online view, open the PROFIBUS diagnostics and confirm every slave is in OPERATE with no parameterization faults.
6. Load shadow batch state. Trigger the batch code to read DB 902 and restore the last snapshot. Operator confirms "Resume Batch" before outputs are re-enabled.
7. Update HMI / ProTool. Restart ProTool/Pro Runtime on PC-B (or have it pre-loaded as part of the WinLC project) and verify the operator screen reflects the live process.
8. Document the event. Capture PC-A's diagnostic buffer (if accessible), WinLC log, OPC DA error log, and Windows Event Viewer before any repair.

9. Recipe and Batch State Synchronization

Recipes in a brewing context typically contain grain bill, mash temperatures, hop addition times, fermentation profile, and target gravity. Recipe changes are infrequent (operator-initiated) and can be synchronized by a snapshot-on-save pattern:

• When operator presses "Save Recipe" on PC-A, WinLC writes the recipe to DB 900 and sets flag M50.0 = TRUE.
• A simple VB script in OPC Scout (or a custom OPC UA client) detects the flag, reads DB 900, and writes it to a tagged buffer exposed on PC-B.
• On PC-B, the OPC client subscription writes the buffer into DB 900 on the secondary.

Live batch state uses a different mechanism: the OPC DA subscription updates DB 902 every cycle (250 ms - 1 s). With a 1-second cycle and WinLC OB1 running at 100 ms, the secondary's view of batch state is at most 1 second stale at any moment. After failover, the secondary's batch code reads DB 902 at startup and resumes.

For higher fidelity, replace the OPC DA snapshot with an OPC UA PublishedDataSet on a 100-ms publishing interval. SIMATIC NET V14 SP1 and later support OPC UA publishing at 100 ms; check the SIMATIC NET manual for the exact minimum supported interval in your installed version. OPC UA also adds a method call pattern that avoids polling: PC-A exposes a method SyncState() that PC-B invokes on demand.

Recipe save acknowledgement: after PC-B confirms DB 900 is written, it sets M50.1 = TRUE on its OPC tag group, and PC-A's batch code clears M50.0. If PC-A does not see the acknowledgement within 5 seconds, it logs a recipe-sync error to DB 903.

10. Alternative and Adjacent Redundancy Platforms

The PC-pair pattern described here is one of several viable paths. Engineers should compare it against the following alternatives before committing to a design.

Beckhoff TwinCAT 3 Redundancy

Beckhoff's TwinCAT 3 supports redundancy for both control and communication processes. TwinCAT redundancy can be configured for warm-standby controllers that synchronize via TCP, with automatic or manual takeover. The relevant product page is at Beckhoff TwinCAT 3 Redundancy. TwinCAT redundancy is licensed per controller pair and offers faster failover than the manual WinLC pattern, at the cost of replacing the Siemens software stack with Beckhoff. For a new build where PLC code is being written from scratch, TwinCAT redundancy is a credible alternative; for an installed WinLC base, migration cost usually outweighs the failover-time improvement.

Siemens WinCC Unified RT Redundancy

For the HMI layer, WinCC Unified (TIA Portal V17 and later) ships a runtime redundancy that pairs two HMI servers with a diagnostics screen template. The signal lights and diagnostics overview are documented at WinCC Unified RT Redundancy Functions. For a brewing line, pairing the WinLC hot-standby with a WinCC Unified redundant HMI pair gives four-PC redundancy (2 controllers + 2 HMIs) without changing the WinLC topology described in this article. WinCC Unified redundancy operates at the HMI layer only — it does not cover the controller fault scenario addressed here.

Siemens S7-400H

For applications where a 10-minute outage is not tolerable, the SIMATIC S7-400H pair delivers < 100 ms bumpless failover over a fiber-optic sync link. Hardware cost is roughly 5-10x the PC-pair, but the resulting system is SIL-capable and supported by Siemens as a redundancy product. Reserve S7-400H for processes where the cost of an uncontrolled stop exceeds the cost of the redundancy hardware — typically continuous chemical or power processes, not batch brewing.

WinAC RTX F (Safety)

WinAC RTX F (fail-safe variant) is a TÜV-certified soft PLC for SIL 2 / SIL 3 applications. It is the only WinAC variant that supports certified redundancy patterns. If the brewing application is part of a larger process with safety interlocks (e.g. CO₂ detection in confined spaces, steam burns from mash tun), WinAC RTX F should be considered even when the underlying process is non-critical.

11. Commissioning Tests and Verification

The PC-pair topology must be commissioned with the same rigor as a vendor redundancy solution. The following test matrix should be completed and signed off before production use.

Each test should be documented with timestamp, operator, observed values, and any fault codes (WinLC fault codes are documented in the WinAC RTX manual — typical values include SF (system fault), BF (bus fault), and the diagnostic interrupt OB82 with event ID 0x3924 for PROFIBUS master failure).

12. Troubleshooting Matrix

Common faults encountered after commissioning, with their root cause and remediation.

FAQ