Recovering Redundant PCS 7 OS Servers and Restoring Redundancy Synchronization
Following a catastrophic operating system freeze or disk crash on a redundant SIMATIC PCS 7 OS Server, restore operational synchronization by rebuilding the failed node using verified image backups or clean software reinstallation matching the partner server's exact hotfix level. Once the PC station configuration and network adapter priorities are restored, configure the WinCC project path, perform a Target OS Download from the ES, and activate WinCC Runtime. The partner OS Server automatically detects the recovering node and initiates an online archive synchronization (Redundancy Synchronization) over the redundant network link, backfilling missing alarms and trend segments without stopping process operations.
Table of Contents
- Redundant Architecture Overview and Failure Modes
- Rebuilding Failed Server Hardware: RAID, Hostnames, and Network Priority
- Target OS Download and Redundancy Activation Workflow
- Redundant OS Server Recovery and Synchronization Phase Matrix
- Verification
- Limitations and Operational Precautions
- Engineer FAQ
- Technical References
- Related Articles
- Related Tags
Redundant Architecture Overview and Failure Modes
In a redundant SIMATIC PCS 7 Operator Station pair (OS Server Master and OS Server Standby), both servers run independent WinCC runtime projects in parallel, acquiring data cyclically from S7-400 controllers over the Plant Bus. The two servers maintain continuous synchronization of alarm logs, process value archives, and operator messages via a dedicated redundancy connection over the Terminal Bus or a cross-connect cable.
When one server suffers a catastrophic hardware failure (e.g. RAID disk failure or kernel crash):
- The surviving partner immediately assumes sole master responsibility, maintaining unbroken visualization and control for all connected OS Clients.
- The surviving server starts an internal redundancy delta log, tracking all alarms, acknowledgments, and trend tags logged during the outage.
- Once the failed server is repaired and rebooted, WinCC Redundancy automatically executes Archive Synchronization (
Archivabgleich) to copy all missed records into the recovering server's local SQL database.
Rebuilding Failed Server Hardware: RAID, Hostnames, and Network Priority
To ensure seamless recovery without destabilizing the running partner server, adhere to strict hardware alignment rules:
- Exact Hostname Matching: Configure the Windows computer name to match the exact station name defined in SIMATIC Manager HW Config. Do not alter the hostname during reinstallation.
- Network Adapter Binding Order: In Windows Network Connections, configure adapter bindings so that the Terminal Bus adapter resides at the top priority of the binding order.
- SimaticRights and User Groups: Verify that the Windows user account belongs to the local groups
SIMATIC HMI,SIMATIC NET, andAdministrators. - Station Configuration Editor: Clear any old caches using
s7cfg.exe /clearand re-import the.xdbconfiguration file to bind the WinCC Application and CP 1623 virtual backplane slots.
Target OS Download and Redundancy Activation Workflow
Follow this sequence to redeploy the project and synchronize redundancy:
- Check Surviving Partner: Confirm that the surviving OS Server is operating stably without errors and that OS Clients are connected to it.
- Target OS Download from ES:
- In SIMATIC Manager on the Engineering Station, right-click the repaired OS Server object.
- Select PLC -> Download.
- Select Scope: Entire project.
- Verify that the project files transfer cleanly to the target server's shared project directory. - Activate WinCC Runtime:
- On the repaired server, open WinCC Explorer.
- Click Activate (Runtime button). - Monitor Automated Archive Synchronization:
- WinCC Redundancy detects the online transition of the partner.
- The surviving server transmits the queued delta archive records over the network.
- Internal system tag@RedundancyStatetransitions from 0 (fault) to 1 (synchronized).
Redundant OS Server Recovery and Synchronization Phase Matrix
The following table details system states, diagnostic tags, and required actions across redundancy recovery phases:
@RedundancyState)@RedundancyState = 0@RedundancyState = 2@RedundancyState = 2@RedundancyState = 1[!NOTE]
Commercial Accuracy Notice: Redundant OS Server configurations require SIMATIC PCS 7 OS Software Server Redundancy licenses > (6ES7658-2CX58-0YH5+6ES7652-3AA00-0YA0). Both physical servers must be individually licensed for equal Process Object > capacities. Software recovery procedures consume no supplementary licenses.
Verification
Verify that server redundancy and synchronization are fully operational:
- Redundancy State Tag Verification: In WinCC WinCC Explorer -> Tag Management, monitor internal tag
@RedundancyStateor open@Redundancy.pdl. Confirm that the state indicates fully synchronized (1). - Alarm Logging Synchronization Check: Trigger a test alarm. Acknowledge it on Server 1 and verify that it acknowledges simultaneously on Server 2 within 1 second.
- Client Failover Test: On an OS Client, verify that the server status overview indicates both Server 1 and Server 2 as healthy, with connection seamlessly established to the primary partner.
Limitations and Operational Precautions
Observe these guidelines during redundancy recovery operations:
- Never Activate Both Servers from Scratch Simultaneously: When bringing up a redundant pair, always activate the designated master first, wait for runtime to establish AS communication, and then activate the standby node.
- Synchronization Bandwidth: During high-volume archive synchronization following a long outage, network traffic on the terminal bus increases. Avoid running heavy engineering compiles during synchronization.
- Identical Software Service Packs: Ensure both servers run identical PCS 7 versions, updates, and hotfixes. Mismatched software revisions can cause synchronization handshakes to fail.
Engineer FAQ
How long does WinCC Redundancy synchronization take after a server is restored?
Synchronization duration depends on the outage length and archive volume. Typically, an outage of several hours synchronizes within 5 to 15 minutes over a Gigabit terminal bus connection.
Do I need to stop the surviving server to synchronize the repaired one?
No. The surviving server must remain in RUN. It continues to control the plant and automatically streams missed data in the background while operating online.
What internal tag tells me if redundancy is healthy?
The system tag @RedundancyState (or @RedundancyError) indicates health. An @RedundancyState value of 1 indicates redundancy is fully synchronized.
Can I restore an OS server using an image backup of the partner server?
Not directly without sanitizing. Cloning a partner server directly duplicates computer names, IP addresses, and WinCC project GUIDs, which breaks redundancy. If using an image, Sysprep or update the station name and XDB configuration.
Technical References
- SIMATIC PCS 7 Fault-Tolerant Process Control Systems (Entry ID 109780813)
- WinCC V7.4 Redundancy Configuration Manual (Entry ID 109736226)
- SIMATIC PCS 7 PC Configuration Guide (Entry ID 109754984)
- Siemens Industry Online Support FAQ on OS Server Redundancy Recovery (Entry ID 109756825)
Related Articles
- Resolving WinCC OS Server S7 Connection Failures After Adding New Plant Areas
- Why Manual File Copying of WinCC Projects from ES to OS Fails in PCS 7
- Resolving ES to OS Download Failures and Security Rights in SIMATIC PCS 7
- Diagnosing and Resolving Station Configuration Editor 5% Boot Hangs in PCS 7
Related Tags
- OS Server Redundancy
- Archive Synchronization
- RedundancyState
- Target OS Download
- Disaster Recovery
- WinCC Redundancy