Recovering Redundant PCS 7 OS Servers and Restoring Redundancy Synchronization

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

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):

  1. The surviving partner immediately assumes sole master responsibility, maintaining unbroken visualization and control for all connected OS Clients.
  2. The surviving server starts an internal redundancy delta log, tracking all alarms, acknowledgments, and trend tags logged during the outage.
  3. 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:

  1. 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.
  2. 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.
  3. SimaticRights and User Groups: Verify that the Windows user account belongs to the local groups SIMATIC HMI, SIMATIC NET, and Administrators.
  4. Station Configuration Editor: Clear any old caches using s7cfg.exe /clear and re-import the .xdb configuration 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:

  1. Check Surviving Partner: Confirm that the surviving OS Server is operating stably without errors and that OS Clients are connected to it.
  2. 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.
  3. Activate WinCC Runtime:
    - On the repaired server, open WinCC Explorer.
    - Click Activate (Runtime button).
  4. 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 @RedundancyState transitions 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:

Recovery PhaseSurviving Partner StateRecovering Server StateDiagnostic Tag (@RedundancyState)Redundancy Synchronization ActionPhase 1: Server FailureMaster (Sole runtime)Offline / Crashed@RedundancyState = 0Surviving partner begins delta trackingPhase 2: Hardware RebuildMaster (Sole runtime)Windows boot / Station ConfigN/AConfigure network adapters, import XDBPhase 3: Target DownloadMaster (Sole runtime)WinCC project loaded (Inactive)N/ADownload entire project from ESPhase 4: Runtime ActivationMasterRuntime starting up@RedundancyState = 2Connection established; handshake initiatedPhase 5: Archive SynchronizationMaster (Transmitting)Standby (Receiving)@RedundancyState = 2Historical alarms and trend tags synchronizedPhase 6: Redundancy RestoredMaster (Fully redundant)Standby (Fully redundant)@RedundancyState = 1System 100% redundant; clients balance connections

[!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:

  1. Redundancy State Tag Verification: In WinCC WinCC Explorer -> Tag Management, monitor internal tag @RedundancyState or open @Redundancy.pdl. Confirm that the state indicates fully synchronized (1).
  2. 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.
  3. 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:

  1. 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.
  2. 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.
  3. 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

Related Articles

Related Tags

  • OS Server Redundancy
  • Archive Synchronization
  • RedundancyState
  • Target OS Download
  • Disaster Recovery
  • WinCC Redundancy
6 respuestas