WinCC 7.4 Process Historian Tag Data Missing After Project Duplication

When a WinCC 7.4 system with a redundant pair of OS servers, an Engineering Station (ES), and a Process Historian server is updated through the WinCC Project Duplicator tool, a well-known cache-synchronization defect can leave the Historian receiving alarm messages while refusing to accept runtime tag values. This article documents the exact symptom, the underlying cache-architecture cause, the official SFCache/PHReady cache recovery procedure, the version-precondition checks that must be in place before the procedure is run, and the verification sequence that proves recovery has succeeded.

1. Problem Definition and Symptom Matrix

The defect presents itself as a partial Historian feed rather than a complete outage. Before starting any recovery procedure, capture the symptom precisely so that the wrong fault path is not entered.

The single most diagnostic entry is the Tag recovery: Needed field under PH Management Console → Data Sources. If alarms are present but tag recovery has not flipped to Not needed after the redundancy handover is complete, the OS-to-PH handshake is in a corrupted state and the SFCache/PHReady cache recovery procedure must be executed.

2. Affected Versions, Topology, and Architectural Constraints

The defect is reproducible on the following baseline. Use this as the precondition filter before applying the procedure; other versions may have different cache layouts.

• WinCC: V7.4 (any Update, including Update 9 and later). Compatible bases: V7.3, V7.4, V7.4 SP1. V7.5 introduces a different PH Ready cache structure (PHReadyConfigV2).
• Process Historian: 2014 SP2 (build 7.4.1.x) and Information Server 2014 SP2. Note: PH 2014 SP2 is the matching revision for WinCC V7.4; mismatched PH Ready component versions are the most common cause of “Tag recovery: Needed” not clearing.
• SQL Server used by PH: as required by the PH 2014 SP2 setup (SQL Server 2014 SP2 standard or higher is typical).
• Topology: 1 × ES (Engineering Station) with WinCC Explorer only (no SIMATIC Manager), 2 × OS Servers with one designated as Redundancy partner, N × WinCC Clients always connected, 1 × Process Historian Server (separate machine), 1 × Information Server optional.
• Project transfer mechanism: WinCC Project Duplicator (Save As from ES to OS), used because the ES does not have SIMATIC Manager and the project must be transported without deactivating both OS servers simultaneously (clients must stay online).

3. Root Cause Analysis

The tag-value write path from an OS server to the Process Historian consists of three queues that must be synchronized with the active PH Ready configuration:

1. PH Ready Cache (AlgCSDataQueue family) — OS-side compressed tag data, located under C:\ProgramData\Siemens\SFCache in folders whose names end with Queue. These files hold the compressed tags waiting to be shipped to PH.
2. S&F Cache (Store and Forward Cache) — OS-side pending segments queued for delivery to PH when the PH Server is offline or slow.
3. Processhistorian.cfg — OS-side handshake file that identifies the PH Server, database, port, and segment format. Located in the active WinCC project folder of the OS server (typically <ProjectPath>\<ComputerName>\Processhistorian.cfg).

When the WinCC project is overwritten by the Project Duplicator on the active OS server, the project folder content is replaced but two side-effects occur:

• The Processhistorian.cfg referenced by the active WinCC Runtime is the file the runtime opened on activation. Project Duplicator overwrites it on disk, but the OS Runtime keeps the previous in-memory handle and writes compressed tag data into the old SFCache/PHReady cache mapping until the next restart.
• The standby OS server is duplicated next, restarting the redundancy handover. The standby now runs with the new Processhistorian.cfg, but the master has not been bounced and still points to the old cache schema. The PH server sees inconsistent writers, drops the tag-value stream, and only accepts the alarm stream because alarms are routed through a different DLL (CCAlgCSData.dll alarm path) that does not depend on the PH Ready cache.

Result: the PH database receives alarms but no tag values; the Tag recovery field remains Needed indefinitely.

4. Pre-Procedure Safety Checks

Before any cache manipulation, perform the following verifications to avoid corrupting the PH database or losing buffered segments.

5. SFCache and PHReady Cache Recovery Procedure

The procedure below is the field-proven recovery sequence. It forces both OS servers to drop their in-memory PH handshake, regenerate Processhistorian.cfg from the freshly duplicated project, and flush the PHReady Cache and S&F Cache so the PH server can rebuild the tag-value stream.

5.1 Phase A — Standby OS Cache Flush

1. On the standby OS server, deactivate WinCC Runtime. Do not shut down the OS. Use WinCC Explorer → File → Activate to deactivate.
2. Rename Processhistorian.cfg in the standby OS project folder to Processhistorian.cfg.old. Example path: D:\WinCCProjects\PlantA\OS_STANDBY\Processhistorian.cfg → Processhistorian.cfg.old.
3. Restart the standby OS server (full reboot, not just WinCC Runtime restart). This is required because the PH Ready service holds open file handles into the PHReady Cache.
4. After reboot, activate WinCC Runtime on the standby OS.
5. Open WinCC Redundancy Diagnostics on the standby OS. Wait until the redundancy check completes and the standby reports Connected to the master.

5.2 Phase B — Master OS Cache Flush

1. On the master OS server, deactivate WinCC Runtime.
2. Rename Processhistorian.cfg in the master OS project folder to Processhistorian.cfg.old.
3. Restart the master OS server.
4. Activate WinCC Runtime on the master OS. WinCC will detect the missing Processhistorian.cfg and regenerate it from the duplicated project.

5.3 Phase C — PHReady Cache and S&F Cache Deletion

1. Backup the SFCache folder from both OS servers:
   robocopy "C:\ProgramData\Siemens\SFCache" "D:\backup_SFCache_<timestamp>" /E /ZB /R:1 /W:1
2. On both OS servers, navigate to C:\ProgramData\Siemens\SFCache.
3. Delete the PHReady Cache folders: any folder whose name ends with Queue, for example AlgCSDataQueue, AlgCSAlarmQueue, MsgArchiveQueue. The PHReady Cache is the OS-side buffer of compressed tag data waiting to be shipped to PH.
4. Delete the S&F Cache files: typically *.dat, *.idx, *.hdr in the SFCache root. These are Store-and-Forward segments held when PH is unreachable.
5. Do not delete the parent SFCache folder itself — only its contents.

5.4 Phase D — Restore Handshake Files

1. On the standby OS, rename Processhistorian.cfg.old back to Processhistorian.cfg.
2. On the master OS, rename Processhistorian.cfg.old back to Processhistorian.cfg.
3. Deactivate the WinCC Runtime on the standby OS.
4. Activate the WinCC Runtime on the standby OS.
5. Wait until redundancy check completes on the standby OS (Redundancy Diagnostics tool, both servers tick Connected).

5.5 Phase E — Final Master Cycle and Recovery Wait

1. Deactivate the WinCC Runtime on the master OS.
2. Activate the WinCC Runtime on the master OS.
3. Wait for the S&F recovery to complete. Open WinCC Redundancy Diagnostics and monitor the S&F Status field; it transitions from Recovery to Synchronized when all segments have been delivered to PH.
4. Open the Process Historian Dashboard and confirm both Tag Data Transfer and Alarm Data Transfer indicators are green.

6. Verification Procedure

Recovery is confirmed by four independent checks. If any check fails, return to Phase A and inspect the version pre-condition in section 4, check #1.

7. Common Fault Conditions That Mimic This Defect

If the recovery procedure completes without errors but tag data still does not arrive, one of the following hidden conditions is typically present. Treat this as a differential diagnosis matrix.

8. Preventive Measures for Future Project Transfers

The defect recurs whenever the Project Duplicator is used without a coordinated OS runtime cycle. Apply the following sequence on every future transfer to keep the PH handshake consistent.

1. Before starting the duplication, deactivate only the standby OS Runtime. Keep the master OS Runtime active and clients connected.
2. Run the WinCC Project Duplicator from the ES against the standby OS first.
3. Activate the standby OS Runtime and wait for redundancy to resync (WinCC is Sync tick on both).
4. Perform a controlled redundancy switchover: deactivate the current master, allow the standby to assume master role, then activate the new standby (the original master).
5. Repeat the Project Duplicator against the new standby.
6. After the final duplicate, perform a Phases A–E SFCache and PHReady cache flush only if Tag recovery: Needed appears in PH Management Console. If it does not appear, no cache flush is required — the duplicate landed cleanly.
7. Always confirm that the PH Ready component version is identical on both OS servers and the PH server before, not after, the transfer.
8. Maintain a scheduled task on the ES that captures Processhistorian.cfg checksums from both OS servers and compares them after every transfer; mismatches are an early warning of the impending tag-data outage.

9. Related System Tags and Diagnostic Surfaces

For Information Server dashboards or WinCC Online Trend Controls that need to surface PH health to operators, the following internal WinCC system tags can be referenced. Note that the status tags exposed by PH must be entered as raw tag names; they are not browseable through the standard tag dialog.

• @PHConnectState — connection state to PH server (0 = disconnected, 1 = connected).
• @PHRecoveryState — tag recovery state (0 = not needed, 1 = needed, 2 = in progress).
• @PHServerName — configured PH server name string.
• @PHDatabaseName — configured PH database name string.

These tags can be wired into a WinCC Alarm or shown on a WinCC picture via direct tag entry. For TIA Portal-based RT Professional installations, the equivalent tag interface is documented under “Configuring runtime settings for Process Historian (RT Professional)” in the official Siemens documentation, available at docs.tia.siemens.cloud.

10. Field-Proven Notes and Caveats

• Do not interrupt Phases A–E with project changes. Each Phase must complete before the next is started, otherwise the S&F Cache and the Processhistorian.cfg handshake can drift further out of sync.
• If the system uses WinCC V7.5 or later, the PHReady cache folder layout changes to PHReadyConfigV2; the procedure above remains valid but the cache folder names differ. Always verify the cache folder naming on a test system before executing on production.
• If a third-party backup tool is configured to snapshot C:\ProgramData\Siemens\SFCache while WinCC is running, it can cause partial writes that look identical to the cache-corruption symptom described in section 3. Disable file-level backup of the SFCache path and rely on SQL-level backup of the PH database only.
• The Information Server 2014 SP2 add-on is independent of the PH Ready cache. If the Information Server also stops displaying tag trends after the procedure, check the Information Server data source refresh schedule rather than re-running the SFCache procedure.
• Never delete C:\ProgramData\Siemens\SFCache itself; only its contents. Deleting the folder itself removes Windows ACL permissions that the WinCC installer restores only on full reinstall.
• The two OS servers must be rebooted in Phases A and B — not just WinCC Runtime restarted. The PH Ready service retains file handles into the cache until OS reboot.