Eliminating Data Logging Discrepancies in Exported Historical Trends on Redundant WinCC OS Servers

In SIMATIC PCS 7 V8.1 SP1 redundant OS server pairs, minor numerical discrepancies when exporting trend values to Microsoft Excel are caused by independent cyclic data acquisition over separate S7 Named Connections, not serial communication absence or database corruption. Adding serial connections will not resolve the issue. Each server polls the AS controller independently; high-frequency analog signal fluctuations between polling intervals result in slightly different samples being recorded. Redundancy synchronization (CCExpressSync) synchronizes archives only after server outages. To achieve identical exported values, configure deadband hysteresis in Tag Logging, or implement AS-side cyclic archiving using MonAnL with AR_SEND.

Executive Summary

Process validation engineers exporting historical trend archives to Microsoft Excel for regulatory batch compliance frequently observe that numerical values logged on OS Server 1 do not match OS Server 2 down to the exact decimal digit. For continuous processes with rapid analog noise (such as slurry flow or high-pressure gas headers), exported tables show micro-fluctuations between redundant partners. Engineers often wonder if adding serial synchronization cables or altering network adapters will force bit-level identity. This guide clarifies the independent acquisition mechanics of WinCC Redundancy in PCS 7 V8.1 and details proven engineering solutions to guarantee identical exported archives.

Architecture and Fundamental Mechanics

The data archiving architecture in WinCC Redundant Server pairs operates through independent acquisition and event-based synchronization:
1. Independent Tag Logging Acquisition:
In a PCS 7 redundant pair, Server 1 and Server 2 run independent WinCC Tag Logging services. Each server establishes its own S7 Named Connection (over Industrial Ethernet using CP 1623 or Softnet-IE) to the S7-400 AS. The servers execute their own internal polling cycles (e.g., 500 ms cyclic acquisition). Because network traffic, interrupt handling, and CPU scheduling are independent, Server 1 might sample the process variable at $t = 100$ ms, while Server 2 samples at $t = 115$ ms. If process noise causes the analog value to ripple, Server 1 records $45.23$ while Server 2 records $45.28$.
2. Scope of Redundancy Synchronization (CCExpressSync):
WinCC Redundancy synchronization is not an ongoing live data reconciler. It is strictly a failure-recovery mechanism. When Server 1 fails or is restarted, Server 2 logs alone. Upon Server 1's return, CCExpressSync copies the missing time slice from Server 2 to Server 1. It never reconciles or overwrites data simultaneously acquired while both servers are healthy.
3. Solutions for Identical Historical Data:
- Method A (Tag Logging Deadband): Applying a deadband (e.g., 0.5% hysteresis) ensures small noise ripples below the physical threshold are ignored, harmonizing logged values.
- Method B (AS-Side Archiving via AR_SEND): Using MonAnL parameter ArchvEn = 1 forces the S7-400 CPU to sample the analog tag, package it into an AR_SEND telegram (SFB37), and transmit the identical data block simultaneously to both servers.

Step-by-Step Implementation Procedure

Understand System Physical Constraints (Do Not Add Serial Cables):
a. Note that modern WinCC Redundancy synchronizes historical archives over the standard Industrial Ethernet Terminal Bus using CCExpressSync.
b. Serial RS-232 connections (such as legacy WinCC Redundancy serial heartbeat cables) are obsolete and have zero impact on Tag Logging numerical data.
Configure Deadband Filtering in WinCC Tag Logging (Method A):
a. Open the OS project in WinCC Explorer and launch 'Tag Logging'.
b. Select the target archive tag (e.g., Flow_Rate_Arch).
c. Open its Properties -> 'Archiving Type' tab.
d. Set 'Hysteresis' (Deadband) to a meaningful process value (e.g., 0.2% or 0.5% of measuring span).
e. This prevents high-frequency noise ripples from triggering divergent archive entries on the two servers.
Implement AS-Side Archiving with AR_SEND (Method B - Exact Parity):
a. Open the CFC chart containing the MonAnL (FB1845) block for the analog transmitter.
b. Set input parameter ArchvEn = 1.
c. Set ArchvCycle to the desired logging interval (e.g., 1 for 1 second, 2 for 5 seconds).
d. The AS controller will now sample the value internally, generate timestamped telegrams via AR_SEND (SFB37), and send the identical telegram to both OS servers simultaneously.
Recompile and Download Changes:
a. In SIMATIC Manager, execute an OS compilation with 'Changes only'.
b. Download OS changes to both redundant servers.
c. Perform a test trend export from both servers into Excel: verify that exported records are 100% numerically identical.

Verification

In WinCC Runtime, open the Trend Control on an OS Client connected to Server 1 and export the past 1 hour of data to CSV.
Switch the client to Server 2 and export the exact same time window to CSV.
Open both CSV files in Microsoft Excel and execute a difference formula (= A1 - B1):
- With AR_SEND or deadband filtering configured, verify that delta values across all rows equal 0.000.
Confirm that WinCC Channel Diagnosis reports healthy S7 Named Connections on both servers.

Limitations and Operational Precautions

Activating AS-side archiving (AR_SEND) increases S7-400 CPU memory and communication load; deploy AR_SEND primarily on regulatory-critical instruments rather than across every non-critical plant tag.

Engineer FAQ

Will adding a serial connection make redundant trend data identical?

No. Serial connections were legacy heartbeats for failure detection; they play zero role in Tag Logging data acquisition or synchronization.

Why do exported Excel values differ between redundant servers?

Because each server polls the AS independently over separate Ethernet connections at slightly different times, capturing high-frequency analog noise differences.

Does CCExpressSync synchronize live data between running servers?

No. CCExpressSync only copies missing archive blocks after a server recovers from downtime; it never compares or overwrites live data logged while both servers are running.