WinCC Redundancy: Project Duplicator vs Manual File Sync

Overview of WinCC Server Redundancy

Siemens WinCC Redundancy is an optional package that pairs two SCADA servers into a fault-tolerant monitoring station. Each partner runs an independent WinCC project, a copy of the same runtime database, and a parallel connection to the AS (automation system). The two servers monitor each other over a dedicated terminal bus (TCP/IP LAN) and automatically fail over if the active partner drops out of service. After the failed server returns, the redundancy option re-synchronizes the runtime databases so both partners return to an identical operating state.

The WinCC V6.2 redundancy option has been carried forward into the V7.x line and into WinCC Runtime Professional in the TIA Portal. The synchronization rules, however, remain unchanged: every change to the project database (tags, alarms, archives, user administration, scripts, connections) must be propagated through the Project Duplicator; only pure graphics assets such as .pdl pictures and .fct functions can be copied by hand between partner folders.

Redundancy Architecture and Data Flow

Two physically separate servers (often labeled Master and Standby, or Server 1 and Server 2) run identical WinCC projects. Each server maintains its own process image; both connect to the same PLCs through independent network paths.

The redundancy process exchanges four types of payload over the terminal bus: process values, alarm messages, archive segments, and partner life-sign messages. The stand-by server buffers these in memory and writes them to disk only when the master acknowledges. When the master becomes unreachable, the stand-by promotes itself to active, becomes authoritative for the HMI clients, and accepts writes. When the failed master returns, the now-active stand-by replays the buffered events back to the recovered server so the on-disk databases converge.

The WinCC Runtime Professional documentation describes this data path in detail: see How Redundancy Works (RT Professional).

Why Project Identity Is Mandatory

Redundancy synchronization relies on matching internal identifiers for tags, messages, archives, and connection points. These identifiers are generated by the WinCC Configuration Studio and stored inside the project database (*.mdf / *.ldf) and the registry hive of each server. If Server A holds tag ID 0x012A and Server B holds tag ID 0x012B for the same logical point, the re-sync handshake treats them as different tags, and the recovered server's database will diverge from the active server's. The runtime will not detect or repair this condition automatically.

The Project Duplicator (German: Projektduplizierung) is the official Siemens tool that performs a guaranteed, transactional copy of all configuration and runtime assets. It updates both the file system and the registry keys that point to those files. Manual file copying touches only the file system; it does not update the registry, which is why a hand-copy is acceptable for graphics but not for database objects.

Decision Matrix: What Needs the Project Duplicator

The underlying rule is binary: if the change is reflected in the SQL Server / Sybase database files inside the WinCC project folder, manual copy is unsafe. If the change is reflected only in .pdl, .fct, or supporting graphical files, manual copy is acceptable.

Case-by-Case Clarification

Each scenario raised in the original engineering exchange is resolved by checking whether the change touches the project database.

Case 1 – Deleting an Unwanted Alarm Message

Removing a row from Alarm Logging on Server A leaves the corresponding row on Server B untouched. After deletion, Server A will not emit that alarm; Server B will, because the row still exists in its DB. Even if the operator manually edits Server B's Alarm Logging to delete the same row, the internal message number remains identical only if the deletion order is preserved. Recommended path: make the change on Server A, then run the Project Duplicator to ship the modified Alarm Logging DB to Server B. The hand-edit-only workflow is technically possible but error-prone and provides no transactional guarantee.

Case 2 – Adding an Alarm (with Existing Tag)

Adding an alarm that references an already-existing tag touches only the Alarm Logging DB, not Tag Management. The tag ID is stable, so the alarm message number will be the same on both servers only if the project's existing alarm numbering is identical. Use the Project Duplicator to keep that numbering deterministic; otherwise drift across long-running deployments will trigger duplicate or out-of-order alarm IDs in HMI clients.

Case 3 – Adding Tags to Tag Management

Tag Management is the most sensitive area. Each new tag is allocated a numeric ID, and the channel unit (e.g., S7-OPC-UA, PROFIBUS, TCP/IP) writes that ID into the registry hive HKLM\SOFTWARE\Siemens\WinCC\.... A hand copy of the project folder leaves the registry untouched on Server B, so Server B will either fail to start the channel or allocate a different ID the next time Tag Management is opened. The Project Duplicator writes both the file and the registry atomically.

Case 4 – Deleting Tags from Tag Management

The deletion path is even more dangerous. After Server A deletes a tag, any alarm, archive, or script that referenced it on Server B will hold a dangling pointer. The runtime on Server B will log "Tag not found" warnings and any redundant re-sync of process values will fail because the tag IDs no longer align. Project Duplicator is mandatory here.

Step-by-Step: Project Duplicator Procedure (WinCC V6.2 / V7.x)

1. Stop WinCC Runtime on both servers. Confirm via the Windows service CCAgent and WinCC Explorer.
2. On the source server, close the WinCC Explorer so the project DB is unlocked.
3. Open Start → SIMATIC → WinCC → Tools → Project Duplicator (German: Projektduplizierung).
4. Select the project path on the source server (default: C:\Program Files\Siemens\Automation\WinCC\WinCCProjects\<ProjectName>\).
5. Enter the destination UNC path of the partner server (e.g., \\SERVER_B\WinCC_Transfer\<ProjectName>\). The destination computer must have WinCC installed and the destination folder must be writeable by the Windows user running the duplicator.
6. Choose Duplicate. The tool performs the following sub-steps:

• Compresses the project (*.zip) on the source machine.
• Transfers the zip to the destination share.
• Extracts the project to the partner's local WinCC project folder.
• Updates the registry hive on the destination server with the matching computer name and local paths.
• Registers the SQL Server / Sybase DB on the partner.

7. Restart the WinCC Runtime on the partner first, then on the source. Verify the redundancy partner handshake succeeds in the WinCC Alarm Control: look for system message 1004033 "Redundancy partner online".

Step-by-Step: Manual Picture / Script Sync

When the change is limited to graphical assets, manual file copy is faster and avoids the project restart that the Duplicator imposes.

1. Stop the WinCC Runtime on the partner (stand-by) server only. The active server remains in operation.
2. Locate the modified file on the source server:
   • Pictures: <ProjectName>\GraCS\<PictureName>.pdl
   • Global scripts: <ProjectName>\library\<ScriptName>.fct
3. Copy the file to the partner's matching subfolder using robocopy, xcopy, or a controlled file-share transfer:

   robocopy "\\MASTER\WinCCProjects\MyPlant\GraCS\" "\\STANDBY\WinCCProjects\MyPlant\GraCS\" *.pdl /MIR /Z /R:3 /W:5

4. Verify file timestamps with dir /T:W on both servers. The picture file size and last-write time must be identical.
5. Restart the partner's WinCC Runtime. The redundancy handshake will reload the picture cache.
6. From a client, force a screen refresh on the partner (touch the picture or use the Reload function in the Picture Window).

The same procedure applies to .fct global functions. Note that runtime-loaded C actions under library\ are compiled to DLLs; if you modify a C action you must also redistribute the rebuilt .dll alongside the .fct.

Hybrid Workflow for Mixed Changes

In real engineering work, picture edits and database edits almost never arrive separately. A practical workflow is:

1. Stage all changes on Server A (pictures, tags, alarms).
2. Run the Project Duplicator to ship the complete project to Server B. This guarantees database consistency.
3. If you must push an urgent picture fix while the duplication is impossible, use the manual copy path for the .pdl only, then schedule a full Project Duplicator run at the next maintenance window.

This hybrid approach is endorsed by Siemens support engineers: hand-copy for pure graphics, Duplicator for everything else, and prefer the Duplicator whenever the change is "small but involves DB."

Verification After Synchronization

Troubleshooting Matrix

Version-Specific Notes

WinCC V6.2

V6.2 uses Sybase SQL Anywhere as the embedded database. The Project Duplicator is delivered under Start → SIMATIC → WinCC → Tools and operates on the *.db file structure. Computer name binding lives in Computer.rt. V6.2 has no online configuration change; every change requires a runtime restart on both partners.

WinCC V7.x

V7.x uses Microsoft SQL Server (initially SQL Server 2005, later 2008/2012/2014 depending on SP). The Project Duplicator logic is unchanged; the tool path is the same. V7 introduces the SIMATIC Shell which can also call the duplicator over a remote shell.

WinCC Runtime Professional (TIA Portal, V15–V20)

RT Professional supports redundancy through the TIA Portal project engineering. Configuration is done in the device configuration of the HMI station; no separate "Project Duplicator" exists because the project is compiled and downloaded to both runtime PCs. Manual file copy is not a supported workflow; re-deployment is performed by re-downloading the TIA project. Refer to How Redundancy Works (RT Professional) for the current architecture.

Capacity and Performance Considerations

Synchronization traffic scales with archive and alarm volume. For typical process plants:

• Process value synchronization: 10–50 ms per batch on a 100 Mbit terminal bus.
• Alarm message synchronization: 5–20 ms per message.
• Archive re-sync after failover: bounded by archive segment size; a 1-hour segment at 1000 tags × 1 s sample requires roughly 90 seconds of catch-up on a healthy network.

For very large installations (50 000+ tags), Siemens recommends a dedicated gigabit terminal bus and the "Redundancy" option with the high-performance tuning profile documented in WinCC Options Redundancy.

Safety and Operational Notes

FAQ