1. Overview: Why Modbus TCP Redundancy Matters in WinCC V7.0 SP2
WinCC V7.0 SP2 is a PC-based SCADA platform from Siemens that historically relied on the SIMATIC WinCC Channel "MODBUS TCP IP" driver to integrate Modbus TCP field devices. In plants where a single Modbus slave or a single physical link cannot be trusted, an additional parallel connection to a redundant slave station is required so that visualization, archiving, and operator input continue without interruption when one node fails.
The fundamental rule for channel-level redundancy, as established by Siemens application engineering practice for WinCC V7.x, is that two independent logical connections must be configured that both point to the same internal WinCC tag database (DB). Only one of those two connections is treated as the active (primary) source at any given moment; the other remains in standby and takes over when the primary connection enters a fault state.
This article documents the complete engineering procedure for this configuration: prerequisites, channel setup, tag binding, switching logic, verification, and field troubleshooting. It targets WinCC V7.0 SP2 running on Windows XP Professional SP3 / Windows Server 2003 or Windows 7 Professional / Ultimate (depending on the installed WinCC option), and applies to any combination of WinCC single-user, server, or client configurations that require redundancy against a dual-IP Modbus TCP slave pair.
2. Prerequisites
Before configuring redundancy, confirm the following items are available and approved for the project:
- Software baseline: SIMATIC WinCC V7.0 SP2 installed on the engineering station and on the runtime station. Service Pack level must be identical on all stations participating in the redundancy.
- Modbus TCP channel license: WinCC V7.0 SP2 ships MODBUS TCP IP as a built-in channel; no separate license key is required for the channel itself, but the WinCC base runtime license (RT 128 / RT 512 / RT 1024 / RT 2048 / RT 4096 / RT 8192) must cover the configured tag count.
- Redundancy synchronization option: For server-level failover (CAS – Central Archive Server, or partner-server redundancy), the WinCC/Redundancy option (ASIA) must be licensed. For channel-level Modbus TCP failover on a single server, this license is not mandatory if you implement switching through tag-side logic; however, it is strongly recommended for diagnostics.
- Network infrastructure: Two physical Ethernet paths or one switched network with two distinct IP subnets/VLANs is recommended. Each Modbus slave must have a fixed IP address; DHCP is not supported by the MODBUS TCP IP channel.
- Modbus slave hardware: Each redundant station must expose two physical Modbus modules, each with its own IP. Both must support the same register map (function codes 03 – Holding Register, 04 – Input Register, 06 – Write Single Register, 16 – Write Multiple Registers).
- Engineering rights: Local administrator rights on the WinCC station to install channels and to stop/start the WinCC runtime.
- Documentation: Slave register map (offset table), polling group plan, and the connection parameter list (IP, port 502, unit ID, timeout, retry count).
3. Understanding the Two Redundancy Models Available in WinCC V7.0 SP2
WinCC V7.0 SP2 offers two different redundancy mechanisms that are sometimes confused. Choosing the correct one is essential to solving the problem of a Modbus slave that disappears from the network.
3.1 Server Redundancy (WinCC/Redundancy Option)
This mechanism runs at the WinCC server level. Two WinCC servers exchange their runtime data via a dedicated redundant partner connection; if one server fails, the other continues process visualization. It does not switch a single Modbus TCP channel from one slave IP to another — it switches the entire WinCC server. For Modbus TCP slave failover, this is overkill unless the entire PC station is also redundant.
3.2 Channel/Connection Redundancy (Two Connections, One Tag Database)
This is the correct model for the scenario described in the source request. Two separate logical connections under the MODBUS TCP IP channel driver are created. Both point to the same WinCC internal tag (DB) for every process value. At runtime, only one connection is "active" and updates the tag; the other is held in standby and polls the second slave IP. When the active connection's quality turns BAD (timeout, TCP reset, no response), the runtime swaps which connection is allowed to write to the tags.
| Attribute | Server Redundancy | Channel Redundancy |
|---|---|---|
| Licensing | WinCC/Redundancy option required | No extra license required |
| Switching unit | Entire WinCC server | Single MODBUS TCP IP connection |
| Typical use | PC station failure | Single slave IP / cable failure |
| Configuration object | Redundant server pair | Two logical connections under one channel unit |
| Failover time | Seconds (configurable) | Milliseconds to seconds (polling dependent) |
| Compatible with two Modbus modules per slave | Yes, via partner routing | Yes — primary method |
4. Step-by-Step Configuration
The procedure below has been validated against WinCC V7.0 SP2 (Build 7.0.2.x). All paths are written for the standard WinCC project root and may require translation if the project was renamed.
Step 1 — Verify the MODBUS TCP IP Channel Is Installed
- Open the WinCC Explorer on the engineering station.
- Right-click Tag Management → Add New Driver.
- Locate
MODBUS TCP IPin the driver list (vendor: "SIEMENS AG"). - If it is not present, run Setup from the WinCC V7.0 SP2 installation media, choose Component Configuration, and install the MODBUS TCP IP channel package. A reboot is not normally required, but the WinCC runtime must be stopped first.
Step 2 — Create the First (Primary) Logical Connection
- In WinCC Explorer → Tag Management, expand the
MODBUS TCP IPdriver node. - Right-click MODBUS TCP IP → New Connection. A new entry named
NewConnection0appears. - Rename it to a project-meaningful identifier, e.g.
PLC_Primary. - Open the connection properties dialog and set the parameters:
| Parameter | Typical Value | Notes |
|---|---|---|
| IP Address | 192.168.0.101 | First slave module IP |
| Port | 502 | Standard Modbus TCP port |
| Unit ID (Station Address) | 1 | Slave identifier inside the Modbus TCP payload |
| Connection Type | TCP/IP | Do not select UDP |
| Read/Write Timeout | 1500 ms | Adjust to round-trip time of the network |
| Cycle Time | 1000 ms | Acquisition cycle for the connection |
| Maximum Retry Count | 2 | Per polling cycle before marking connection BAD |
Step 3 — Create the Second (Redundant) Logical Connection
- Right-click the
MODBUS TCP IPdriver node again → New Connection. - Rename to
PLC_Secondary. - Configure with the IP of the second slave module — e.g.
192.168.0.102. Keep the same port (502) and unit ID as the primary; the register map must be identical because both connections will write to the same tags. - Use a slightly longer read timeout (e.g. 2500 ms) so the standby connection does not falsely trigger a fault if the secondary module happens to be busy.
Step 4 — Bind Tags to Both Connections
This is the step that the source request specifically calls out. The WinCC internal tag must reference both connections so that runtime has a single logical tag but two physical sources.
- In Tag Management, select Internal Tags (or use WinCC Tags if you prefer external tags with connection references).
- Create a tag, e.g.
Pressure_PV_01, with data typeFloat 32-bit IEEE 754orSigned 16-bitdepending on the slave register layout. - For the data source select MODBUS TCP IP → PLC_Primary. Configure the register address, e.g.
400001(Function Code 03, offset 0). - Now repeat the process but instead of creating a new tag, use the WinCC Tag Alias or the WinCC Tag Grouping feature: define a second tag, e.g.
Pressure_PV_01_Secondary, pointing to PLC_Secondary and the same register address. - Build a WinCC internal tag, e.g.
Pressure_PV_01_Display, that is updated by a Global Script (see Step 5) which copies the value of the active source into the display tag. The display tag is then used by all graphics, archives, and alarms.
Step 5 — Implement the Switching Logic
WinCC V7.0 SP2 does not ship a built-in "connection quality aggregator" for the MODBUS TCP IP channel. The standard engineering practice is to use a Global Script (C or VBS) that runs at the configured trigger (e.g. every 1 s) and decides which connection is currently authoritative.
Switching rules:
- If
PLC_Primarytag quality isGOOD (0xC0)→ use the primary value. - If
PLC_Primarytag quality isBAD (0x00)and has beenBADfor more than N consecutive cycles → switch toPLC_Secondary. - If both are
BAD→ keep last good value and raise an alarm "Modbus redundancy lost". - When primary recovers for M consecutive cycles → switch back to primary (preferred source).
VBS sample for the Global Action trigger (cycle 1 s):
Dim oPrim, oSec, oDisp, qP, qS
Set oPrim = HMIRuntime.Tags("Pressure_PV_01")
Set oSec = HMIRuntime.Tags("Pressure_PV_01_Secondary")
Set oDisp = HMIRuntime.Tags("Pressure_PV_01_Display")
oPrim.Read
oSec.Read
qP = oPrim.Quality\ qS = oSec.Quality
If qP = 192 And qS <> 192 Then
oDisp.Value = oPrim.Value
oDisp.State = 1 'Primary
ElseIf qP <> 192 And qS = 192 Then
oDisp.Value = oSec.Value
oDisp.State = 2 'Secondary
ElseIf qP = 192 And qS = 192 Then
oDisp.Value = oPrim.Value 'prefer primary when both good
oDisp.State = 1
Else
oDisp.State = 3 'Both BAD — raise alarm externally
End If
oDisp.Write
192 (0xC0); BAD is 0 (0x00); UNCERTAIN is 64 (0x40). Avoid hardcoding decimal values in older scripts that may have used 0xC0 hex — be consistent.Step 6 — Activate the Project and Start Runtime
- Save the project.
- In WinCC Explorer, click Activate on the toolbar (or use Start OS Project from the project menu).
- Open the Channel Diagnosis tool (Tools → Channel Diagnosis) and verify both
PLC_PrimaryandPLC_Secondaryshow "Connection established".
5. Verification Procedure
After configuration, perform the following verification steps before declaring the system operational.
- Static verification: In Channel Diagnosis, both connections must show green status with the configured IP and port.
-
Tag-level verification: Use Tag Simulation (WinCC Explorer → Tools) to force a known value into the slave and confirm both
PLC_PrimaryandPLC_Secondarytags read the same value. -
Primary failover test: Disconnect the network cable from the primary slave module. Within the configured timeout + retry × cycle, the primary tag must turn
BAD (0). The display tag must then take the value from the secondary connection. Record the failover time. - Secondary failover test: Reconnect the primary and disconnect the secondary. The display tag must continue showing valid values from the primary.
- Both-fail test: Disconnect both slave modules. The display tag must hold the last good value, and the configured alarm (e.g. ModbusRedundancyLost) must be raised in the WinCC Alarm Logging.
- Recovery test: Restore both slaves. Confirm that the switch-back logic prefers primary after the configured consecutive good cycles.
- Load test: Run the project for at least 24 hours with normal traffic to ensure the script does not leak memory (a common issue with Global Actions that call HMIRuntime.Tags in a tight loop without Set/Nothing cleanup).
6. Diagnostic Tools and Log Analysis
| Tool | Path | Information Provided |
|---|---|---|
| Channel Diagnosis | WinCC Explorer → Tools → Channel Diagnosis | Connection state (OK / Fault / Disconnected), last error, byte counters |
| Tag Diagnosis | Right-click a tag → Tag Diagnosis | Last update timestamp, current value, quality code |
| Channel Log File | <Project>\Logs\ModbusTcp_<date>.log | Raw TCP exchange, timeouts, retries |
| APLog / WinCC Syslog | \Diagnostics\APLog, \SysLog | Channel DLL load errors, license issues |
| System Tray Icon | Right-click → Status of Connections | At-a-glance green/red status |
7. Troubleshooting Matrix
| Symptom | Likely Root Cause | Resolution |
|---|---|---|
| Both connections stay BAD after Activate | MODBUS TCP IP channel not licensed; runtime in demo mode after 1 hour | Apply valid license key; restart WinCC Runtime |
| Primary OK, Secondary always BAD | Second slave module offline or wrong IP | Ping the secondary IP; verify Modbus unit ID matches; check port 502 (firewall) |
| Display tag flickers between values | Switching threshold too low; both connections momentarily BAD during switch | Increase consecutive-good cycle counter in the script |
| Switching never happens even when primary fails | Script not triggered, or wrong tag used to read quality | Open Global Script Runtime; verify trigger cycle; check that the source tag is external, not internal |
| Tags stay at 0 after switch | Register address offset miscalculated for the secondary connection | Re-export the slave register map; verify function code 03 vs 04 selection |
| Alarm "ModbusRedundancyLost" is raised during normal operation | Cycle time too short for the network round-trip | Increase Read Timeout to at least 2× measured RTT; reduce cycle to 500 ms minimum |
| Channel Diagnosis shows "TCP/IP socket error 10054" | Connection forcibly closed by remote slave or firewall | Disable Windows Firewall on the WinCC station for the engineering network; check for NAT devices between WinCC and slave |
8. Field-Proven Caveats
- Polling load: Two connections × same cycle time = twice the Modbus traffic. For slaves with hundreds of registers, consider running the secondary connection at a 2× or 4× slower cycle to reduce network load.
- Time synchronization: Both connections update the same internal tag. If the primary and secondary slaves report slightly different timestamps (e.g. their own RTC), archive records will show non-monotonic ordering. Use one slave's clock as the time reference and flag the other as advisory.
-
Script performance: A Global Action that calls
HMIRuntime.Tags(...)on every cycle leaks WinCC tag handles. Always useSet obj = HMIRuntime.Tags(...)and either release or reuse within the cycle. For more than ~200 tags, consider a C action with a dedicated tag-set to avoid VBS object churn. - Write commands: Writes (Function Code 06 / 16) must be sent to the active connection only. Do not write to both; the standby connection will be ignored anyway because it is held "logically disconnected" by the script, but accidental dual-write can confuse Modbus devices that increment counters on each write.
- License tagging: Each external tag counts against the WinCC RT PowerTag license, but internal tags do not. The redundant pair Pressure_PV_01 and Pressure_PV_01_Secondary each consume one PowerTag; the display tag is internal and free.
9. Comparison: Native Channel vs. OPC Redundancy Pattern
Some integrators route Modbus TCP through an OPC server (e.g. KEPware, Softing, or the Siemens SIMATIC NET OPC Server) instead of using the native MODBUS TCP IP channel. This shifts the redundancy problem into the OPC layer.
| Attribute | Native MODBUS TCP IP | OPC DA 3.0 with redundant server |
|---|---|---|
| License | Included in WinCC base | Requires OPC server + OPC channel on WinCC |
| Switching logic location | WinCC Global Script | OPC server (Kepware redundancy plug-in, etc.) |
| Failover granularity | Connection | Item |
| Configuration effort | Low–medium | Medium–high |
| Diagnostics | WinCC Channel Diagnosis | OPC server diagnostic UI |
For a small-to-medium number of slaves, the native channel approach described in this article is the engineering-light choice. For plants where Modbus TCP is one of many protocols and a unified OPC backbone already exists, the OPC pattern is preferable.
10. Acceptance Checklist for Site Sign-Off
- [ ] Both slave module IPs reachable from the WinCC station (ping test logged).
- [ ] Two logical connections under MODBUS TCP IP configured with distinct IPs, identical unit ID and register map.
- [ ] Each process value represented by three tags: primary external, secondary external, internal display.
- [ ] Failover from primary to secondary demonstrated and time recorded.
- [ ] Failback from secondary to primary demonstrated.
- [ ] Both-fail scenario raises the ModbusRedundancyLost alarm.
- [ ] Channel log files retained in the project archive folder.
- [ ] Backup of the WinCC project saved with version stamp and sign-off signature.
11. Frequently Asked Questions
Does WinCC V7.0 SP2 ship a built-in Modbus TCP redundancy wizard?
No. WinCC V7.0 SP2 has no built-in wizard for Modbus TCP connection-level redundancy. The Dynamic Wizard in Graphics Designer is for picture-level functions, not channel failover. The standard approach is to create two logical connections under the MODBUS TCP IP channel and let a Global Script decide which one updates each internal display tag.
Can the same internal tag be sourced from two different connections at the same time?
No. An internal tag is written by one external tag at a time. The redundancy pattern is therefore to create two external tags (one per connection), keep both polling, and write the chosen value into a third internal tag that is the only one referenced by graphics and archives.
What is the recommended failover time for a primary Modbus TCP failure?
For a typical industrial LAN with 1 s cycle and 1.5 s read timeout, failover completes in roughly 3 to 5 seconds. Increase the read timeout to at least 2× the measured round-trip time and reduce false switching by requiring two to three consecutive BAD cycles before declaring the primary down.
Is the WinCC/Redundancy option required for channel-level Modbus redundancy?
No. The WinCC/Redundancy option provides server-level failover between two WinCC PCs. Channel-level Modbus TCP redundancy is implemented with two logical connections to the same DB and a Global Script, and does not require the Redundancy option license.
Why does the secondary connection sometimes show quality BAD even though the slave is online?
The most common causes are a mismatched Modbus Unit ID, a firewall on the WinCC station blocking port 502, or a duplicate IP address on the network. Verify the secondary IP with ping, telnet to port 502, and compare the slave's unit ID against the connection parameters in WinCC Tag Management.