Resolving WinCC CAS Trend Gaps After OS Full Download

Problem Overview

In PCS 7 / WinCC V7 environments with redundant Operator Station (OS) servers and a Central Archive Server (CAS), an OS full download can break the historical data path between the OS TagLogging runtime and the long-term archive on the CAS. The symptom is a trend control that displays process values correctly for the recent online archive window on the OS (typically 1 day to 1 week, depending on the configured swap-out time), and then a flat horizontal line for everything older. Although the same values exist on the CAS, the OS clients cannot retrieve them, and the user sees what looks like a constant value extending back to the configured start time of the trend window.

The constant line is not flagged as an uncertain value (u) or an interpolated value (i). The WinCC process value status flag does not change, so the value still appears as a real measured reading. This makes the problem particularly dangerous in regulated or validated plants, because the operator display does not flag the historical data as missing. The pattern is well known in PCS 7 V8.x, V9.0, and V9.1 with WinCC V7.4 SP1, V7.5, and V7.5 SP1 as the underlying HMI platform, and is the most common CAS-related issue reported with Siemens Industry Online Support after a complete OS download.

Environment and Configuration

The following configuration is the most common pattern that triggers the failure mode:

• Two OS servers configured as a redundant server pair (OS Server 1 / OS Server 2), with hot-standby archive synchronization
• One Central Archive Server (CAS) used for long-term archiving of tag logging and alarm logging data
• Approximately 7,000 long-term trend tags configured on the OS
• OS primary archive holding 1 day to 1 week of online data, with all older segments swapped out to the CAS
• CAS Storage Plus paths configured for both tag logging and alarm logging
• Optional: redundant network paths (backup paths) configured for the tag logging and alarm logging archives on both OS and CAS

The failure normally appears in 50 to 200 tags out of several thousand. In the field case that drove this article, all 100 affected tags belonged to a single AS (Automation Station / PLC) out of five in the project. That is a strong tell that the OS full download re-resolved tag references for the affected AS and silently rewrote the archive connection on the OS side without the matching write into the CAS archive configuration. The behavior is described in the WinCC Information System under Working with WinCC > Tag Logging > Archive Configuration and Redundancy > Archive Synchronization; see the Siemens Industry Online Support portal for the WinCC V7.5 SP1 manual set.

Architecture and Data Flow

The WinCC OS / CAS topology is shown below. The AS pair sends process values to the OS pair over S7 communication. Each OS server runs a local TagLogging runtime that holds 1 day to 1 week of online segments in its local SQL Server instance. Older segments are swapped out to the CAS over the archive server protocol, and the CAS stores them on disk under the Storage Plus paths. WinCC clients query the OS pair for the recent window and the CAS for older data; the OS pair and the CAS together present a single continuous archive to the client.

Root Cause Analysis

WinCC TagLogging is implemented on top of Microsoft SQL Server. Each TagLogging runtime is a SQL Server instance with its own database (typically CC_TLG_xxx). The CAS runs the same engine and receives swapped-out segments from the OS server via the WinCC archive server protocol. When the OS is fully downloaded, the WinCC Explorer project on the OS server is regenerated and the TagLogging start configuration is rebuilt. The swap-out time, segment change criterion, and storage location are normally preserved, but three things can break the chain to the CAS:

1. Catalog mismatch. The OS TagLogging runtime no longer holds the historical segment IDs that the CAS uses as keys. The CAS still has the segments in Storage Plus, but the OS query to the CAS no longer resolves a tag-name-to-segment mapping for the affected tags. The OS substitutes the last known value as a constant for the missing historical window.
2. Backup path misdirection. Backup paths or additional storage locations configured for the tag logging and alarm logging archive are left in place after the download. When two paths are configured, the runtime alternates writes between them, and the segment that the CAS owns may live in the offline path. The OS sees a missing segment and substitutes the last value as a constant. The field case showed exactly this: a re-install of the CAS did not fix the problem, but removing every backup path and re-running a complete download did.
3. Time synchronization drift. The "1-week" boundary that the operator sees is exactly the configured swap-out time on the OS, and a few seconds of skew between the segment boundary on the OS and the segment boundary on the CAS is enough to make the OS trend miss the segment join. When all affected tags are clustered in a single AS out of several, time drift on that AS is the primary suspect.

Pre-Diagnosis Checklist

Before changing the configuration, run through the following checks. Each one eliminates a likely cause without disturbing the runtime.

1. Time Synchronization

Open WinCC Explorer on each OS server and on the CAS. Right-click Computer and select Properties. On the Time Synchronization tab, confirm that all three machines point to the same NTP or domain time source, and that the offset is below 1 second. Repeat the check on the AS (in SIMATIC Manager / PCS 7, the time master is configured on the Time-of-Day Synchronization dialog under PC Station properties). The Siemens Industry Online Support portal hosts the SIMATIC Time-of-Day Synchronization documentation.

2. Storage Plus Path Consistency

On the CAS, open WinCC Explorer and confirm that the Storage Plus paths for both tag logging and alarm logging resolve to existing directories, and that the directories have write permission for the WinCC service account. Compare the path on the OS server side: the OS only knows how to query the CAS, but a path mismatch on the OS side will hide the query result from the client.

3. Backup Path Configuration

In the WinCC TagLogging configuration on both the OS and the CAS, click the Archive tab and check the Backup and Additional Backup Target fields. If two paths are configured and one of them points to a network share that is unavailable after the OS download (because the download rebuilt the service account, or because a DNS or SMB signing change took effect), the runtime silently fails the write to that path and the affected segments end up orphaned. The OS still thinks they exist.

4. Segment Change and Swap-Out Time

In the same dialog, capture the Segment Change (Daily / Weekly / Monthly / Size-based) and the Swap Out Time from the OS server. The "1 week" behavior that operators see in the trend is most often the configured swap-out time, not the segment change. If the swap-out time has been changed in the OS project after the download without a matching change on the CAS, the OS holds a window of data the CAS does not have, and the CAS holds a window the OS no longer asks for.

Step-by-Step Resolution

The field-proven sequence that resolves the issue without losing CAS data is as follows. The two key preconditions are detaching the data on the CAS before any re-install, and removing every redundant backup path before the next download.

Step 1 - Capture the existing configuration

On the CAS and on both OS servers, take screenshots of:

• TagLogging configuration (all four tabs: Archive, Archive Configuration, Tag Selection, Parameters)
• AlarmLogging configuration
• Storage Plus paths
• Time synchronization settings
• The Computer > Properties > Startup dialog

Export the WinCC project on each machine. The export contains the archive configuration; the runtime database contents stay in the local SQL instance.

Step 2 - Detach the data on the CAS

Open the WinCC Archive Connector configuration on the CAS. Right-click the relevant archive group and select Detach. This stops the CAS from accepting new segments from the OS for the affected tags but does not delete any segment on disk. The segments remain in the Storage Plus directories and remain readable once the OS is reconnected with a matching configuration.

Step 3 - Remove all backup paths for tag and alarm logging

On the OS servers, open Tag Logging > Archives > Properties. On the Archive tab, clear the Backup path and remove any Additional Backup Target. Repeat for the Alarm Logging configuration. Save the project.

On the CAS, repeat the same removal. The rule is simple: a single storage path per archive, no backup path, no additional backup target. The OS full download will then re-create the same single path consistently on both sides.

Step 4 - Re-attach the data on the CAS

After the OS project is reloaded (see Step 5), re-attach the archive on the CAS. The segments in Storage Plus are now indexed against the OS that is asking for them. To re-attach, in the Archive Connector, right-click the archive group and select Attach. Browse to the Storage Plus directory and select the segment catalog file. The CAS rebuilds the index from the existing files; no segment data is touched.

Step 5 - Perform a complete OS download

On the engineering station, open the PCS 7 project and execute OS > Download > Complete download to target station for the affected OS server. A complete download is required, not a delta download, because the archive configuration on the OS has been changed. A delta download will leave the old TagLogging configuration in place and the problem will reappear after the next segment change.

Step 6 - Restart the OS servers one at a time

After the complete download, the OS servers must be restarted in the correct order. The first machine to come up will be the master of the redundant pair, and the second machine will resynchronize its archive from the first.

1. Stop the WinCC runtime on both OS servers.
2. Start the CAS first (if it was stopped) and wait until all services are up. Verify the Archive Connector is in Running state.
3. Start OS Server 1. Wait until the WinCC runtime reports Running and the redundancy partner is Standby.
4. Start OS Server 2. Wait until the redundancy state is Standby and the archive synchronization reports Synchronized.
5. From a WinCC client, open a trend for a tag that was previously broken and request a time range that starts before the OS's online archive window. Verify that the trend fills in from the CAS.

Verification

The repair is only complete when all of the following are confirmed:

• From a client, the trend control for each previously broken tag shows real values across the requested time range, with no flat line and no (i) or (u) flagging.
• WinCC TagLoggingRT on the OS server reports no error events in the Windows Application log for the affected tags over a 24-hour window.
• The Storage Plus directory on the CAS contains new segments dated after the restart, and the segment size matches the configured Segment Change.
• The redundant OS pair is in steady state Master / Standby, and the archive sync state is Synchronized on the standby.
• The next scheduled segment change (next day, next week, or next month, depending on configuration) produces segments on both the OS and the CAS, and the OS segments are swap-out candidates to the CAS within the configured Swap Out Time.

Preventive Measures

Three practices prevent the issue from coming back:

1. One path only. Never configure a backup path or an additional backup target for tag logging or alarm logging. The "redundancy" is at the OS pair and at the CAS, not at the file path level. The WinCC Information System documents this in the Archive Configuration > Backup section, available on the Siemens Industry Online Support portal.
2. Single time source. The OS pair, the CAS, the AS pair, and the engineering station must all be on the same NTP source, with NTP polling at 60 seconds or less. PCS 7 supports the SIMATIC Time-of-Day Synchronization protocol on the AS side; configure it on the Time-of-Day Synchronization dialog. Drift below 1 second is the target.
3. Detach before re-install. If a CAS re-install is required, the data must be detached first. A re-install with attached data is the single most common reason a re-install does not fix the issue.

Troubleshooting Matrix

Value Flag Reference

WinCC applies two process value flags to archived values, and reading them correctly is the fastest way to distinguish a real constant reading from a missing-data display:

The flat-line symptom with no flag is the worst case: the OS is returning a numeric value, but it is the wrong value for the requested time. This is why the fix focuses on the OS / CAS query resolution, not on the underlying measurement.

FAQ