WinCC Archive Segment Sizing for 2-Year Data Retention

Overview of SIMATIC WinCC Cyclic Archiving

SIMATIC WinCC stores all process history in three cyclic databases on the WinCC server: AlarmArchive (message events), TagLoggingFast (high-cycle process values), and TagLoggingSlow (long-cycle process values). Each archive is physically implemented as a directory of segment files in the project path \<ServerName>\<ProjectName>\<ArchiveType>. Every archive segment is a self-contained .DBF-based or Microsoft SQL database file that can be opened, copied, or backed up independently. The number of segments, the change trigger, and the per-segment size limit all directly determine how long a history is retained before the oldest segment is overwritten or relocated by the swap-out mechanism.

For a target retention of two years on a 1.5 TB hard disk, the engineering task is twofold:

1. Calculate the daily write volume per archive to ensure that the disk can hold the entire retention window.
2. Configure the Segment Change parameters so that the resulting number of files remains serviceable for swap-out, backup, and trend re-display.

The calculation method described below is derived from the formulas used in the official WinCC sizing documentation, in particular the entry "How do you calculate the data volume for WinCC archives?" on the Siemens Industry Online Support portal, and the segment-change semantics described in "What is the meaning of the 'Time of the segment change' setting option?".

Archive Types and Default Paths

Three cyclic archives are created automatically the first time a project is activated. Their default paths and primary use cases are summarized below.

Each archive is a series of segment files named S<YYYYMMDD>-<HHMMSS>.DBF (WinCC V7.x) or S<YYYYMMDD>-<HHMMSS>.mdf (WinCC V8.0 with SQL backend). The numeric prefix increments with each change trigger, allowing the runtime to identify the oldest segment for swap-out or deletion.

Segment Change Triggers

Two independent triggers cause WinCC to close the current segment and open a new one:

1. Time trigger - configurable as Daily, Weekly, Monthly, or Yearly. The change occurs at the configured time of day (default 00:00:00) for daily, at 00:00 on Monday for weekly, and at 00:00 on day 1 of the month for monthly.
2. Size trigger - a hard size limit (1 MB to 2 GB, default 1 GB for TagLoggingFast/Slow and 32 MB for AlarmArchive). When the current segment reaches the limit, the runtime rolls to a new segment even if the time trigger has not elapsed.

Both triggers are evaluated in the runtime, and the first one to fire wins. This means that with a daily time trigger and a 1 GB size limit, a high-rate archive may produce several segments per day; conversely, a low-rate archive configured with a daily trigger may keep a single segment open for weeks if the size limit is not reached.

Storage Sizing Methodology

The total disk volume required for an archive is the sum of all segment files that must be resident on disk at the moment the oldest data point is one retention-period old. Because segments are atomic and are deleted (or swapped to long-term storage) only when they are no longer the oldest, the disk must hold one full retention period of segments, not just the steady-state write rate.

Per-Tag Daily Volume

A single archived value is stored as a tuple of (timestamp, value, status). For a float32 tag this is typically 16 bytes (8 bytes timestamp, 4 bytes value, 4 bytes status, plus internal padding). A double tag requires 24 bytes. A binary tag requires 12 bytes. Add an index overhead of approximately 30%.

Where t is the acquisition cycle in seconds. For 1 s, 5 s, 10 s, and 60 s cycles the float32 footprint is approximately:

• 1 s: 1.80 MB/day per tag
• 5 s: 0.36 MB/day per tag
• 10 s: 0.18 MB/day per tag
• 60 s: 0.030 MB/day per tag

Alarm Archive Volume

Each alarm event occupies approximately 256 bytes in compressed form (state + timestamp + operator + text pointer). With N events per day:

V_alarm = N × 256 × 1.10 bytes/day

Typical plants emit 100 to 10 000 alarm events per day, yielding 28 KB to 2.8 MB/day - negligible compared with tag volumes.

Total Retention Volume

For a retention period of R days and k tag groups with daily volume V_k:

V_total = R × (Σ V_k + V_alarm) + Slack

Reserve Slack = 1.25 × V_total to cover swap-out, log files, and the OS page file. With a 1.5 TB disk, plan to keep the archive set below 1.2 TB to leave headroom for the page file and WinCC project backups.

Worked Example: 1.5 TB / 2-Year Retention

Assume the following typical plant configuration:

Over 2 years (730 days) without compression:

V_total = 730 × 432 MB ≈ 315 GB

Apply the 1.25 slack factor: 315 × 1.25 ≈ 394 GB.

Calculating the Number of Segments

The number of resident segments is determined by the segment-change cadence and the size limit:

N_segments = ceil( V_per_period / S_limit ) × N_periods_in_retention

Where:

• V_per_period is the volume written in one segment-change interval.
• S_limit is the configured per-segment size limit.
• N_periods_in_retention is the number of change intervals in 730 days.

For the worked example with the TagLoggingFast archive (180 MB/day at 1 s) and a 1 GB size limit, a daily change trigger yields:

• V_per_period = 180 MB
• ceil(180 MB / 1 GB) = 1 segment per day
• N_periods = 730 days
• Total segments: 730 for TagLoggingFast alone

Adding the TagLoggingSlow (90 MB/day, 1 GB limit, daily trigger) yields 730 more segments. The AlarmArchive at 0.56 MB/day with a 32 MB limit and daily trigger yields 730 segments of negligible size. Total resident segments on disk: ≈ 2 190 files over the 2-year window.

If the per-segment file count becomes a backup or trend-display concern, switch the time trigger to Weekly or Monthly and raise the size limit so the segment change is driven by time, not by size. The trade-off is that a single segment file becomes much larger (potentially 25 GB for a monthly TagLoggingFast segment), which can slow trend online re-display and increase recovery time from backup.

Recommended Segment Configuration for 2-Year Retention

For plants with high tag counts (> 5 000 fast tags) or strict 2-year retention, raise the per-segment size limit to 2 GB to reduce the file count to one segment per day without the size trigger firing prematurely.

Configuration Procedure

1. Open WinCC Explorer on the server, right-click Tag Logging and select Open.
2. In the Tag Logging editor, select the archive (e.g. TagLoggingFast) and choose Properties > Archive Configuration.
3. In the dialog, locate the field Time of the segment change. Set it to one of: Once a day, Once a week, Once a month, or Once a year. The associated spin box controls the time-of-day for daily/weekly and the day-of-month for monthly/yearly changes.
4. Set Segment size [bytes] to the desired per-file limit. Values from 1 048 576 (1 MB) to 2 147 483 648 (2 GB) are valid.
5. Repeat for TagLoggingSlow and Alarm Logging (the Alarm Logging editor is opened from WinCC Explorer in the same way).
6. Open Computer > Properties > Archives and set the Storage path to a dedicated volume or folder. Do not place archives on the system drive or on a network share - WinCC requires a local, fixed path for cyclic swap-out.
7. Activate the project. The first segment is created on the next segment-change trigger or on the next write after a size trigger.

The dialog layout and field names are described in detail in the WinCC V8.0 Information System under Tag Logging > Archive Configuration > Time of the segment change; cross-reference the same dialog in your installed version, since the field labels differ between V7.4, V7.5, and V8.0.

Long-Term Archiving (Optional Storage Plus / CAS)

If 2-year retention on the local disk is not acceptable, enable the optional Process Historian or WinCC/CAS (Central Archive Server) package. These add-ons copy closed segments to a separate SQL database for long-term storage, while the local cyclic archive continues to overwrite the oldest segment after the configured local retention. The local disk then needs to hold only a few weeks or months of data, not 2 years. Licensing is per archive tag for Process Historian and per server pair for CAS.

Archive Backup, Swap-Out, and Disk Watchdog

By default, when the local archive is full the oldest segment is overwritten. To prevent data loss, configure swap-out in Computer > Properties > Archives > Swap-out:

1. Set Target path to a backup volume or NAS path.
2. Set Swap-out time to a low-traffic window (typically 02:00).
3. Enable Swap-out enabled for each cyclic archive.

For redundancy, use the WinCC Redundancy option to mirror segments in real time to a standby server, or schedule a daily ccbackup.exe job that copies closed segments to a backup folder on a different physical drive.

Verification Checklist

1. After 24 hours of runtime, check \<Project>\Archive\TagLoggingFast and confirm that one or more segment files with the expected naming pattern (S<YYYYMMDD>-<HHMMSS>.mdf) have been created.
2. In WinCC Tag Logging, select any tag and open the trend view. Set the time range to "1 day" and verify that the trend renders without gaps.
3. Open the Alarm Logging editor and verify that messages are visible in the message list and that the AlarmArchive directory contains at least one segment file.
4. Open the Windows Performance Monitor and watch the WinCC Archive Manager counter Segments written - it should increment on every segment change.
5. Calculate the actual write rate from the segment sizes in the archive directory: total bytes / hours elapsed. Compare against the projected rate from the sizing formulas above. A deviation greater than 20% indicates unanticipated tag additions or wrong cycle settings.
6. Use WinCC Diagnostics > Archive Diagnostics (TagLoggingRT.exe) to confirm that the configured segment change time matches the actual file creation time.

Troubleshooting Matrix

Performance Considerations

Segment change is a small but non-zero operation: WinCC closes the current database, performs an internal consistency check, and opens a new file. On a WinCC V8.0 server with SQL backend this typically takes 200 to 800 ms, during which new archive writes are buffered in memory. With a daily trigger at midnight and a stable process, this delay is invisible. However, with a size-trigger rollover occurring during a high-rate batch, the buffered write may exceed the configured queue depth (default 10 000 records) and trigger an overflow alarm. If your plant produces bursts of archive traffic, prefer a time-based segment change so the rollover happens during a quiet period.

For trend online display performance, the WinCC Trend Control reads segments in chronological order. A small number of large segments (e.g. 24 monthly files) is faster to scroll through than thousands of small daily files, but a single corrupted large segment is more disruptive to recover from. For most 2-year retention scenarios, a daily trigger with a 1 to 2 GB size limit is the best compromise.

Sample Calculation Worksheet

Use the following template to size any new WinCC project:

Project:            _______________
Retention target:   ____ days
Local disk size:    ____ TB

Tag group 1:       ____ tags × ____ s cycle × ____ bytes/rec = ____ MB/day
Tag group 2:       ____ tags × ____ s cycle × ____ bytes/rec = ____ MB/day
Tag group N:       ____ tags × ____ s cycle × ____ bytes/rec = ____ MB/day
Alarms:            ____ events/day × 256 × 1.10                 = ____ MB/day
                                              Total            = ____ MB/day
× Retention days                                              = ____ GB
× 1.25 slack factor                                          = ____ GB

Disk headroom check: local disk ≥ 1.25 × GB above → OK
Segment count: retention_days / change_period = ____ segments per archive

Frequently Asked Questions