WinCC v7.0 Project Update Procedure Preserving TagLogging

1. Overview

Updating a deployed Siemens WinCC v7.0 SCADA project in the field is fundamentally different from recompiling an application: the runtime database (ArchiveManager, <Project>RT.mdf, <Project>RT.ldf) is the live historian of the plant, and TagLogging segments, AlarmMessage ring buffers, and user archives must survive the upgrade. This article documents the field-proven procedure to deploy a new WinCC v7.x project revision (graphics, C-scripts, VBA macros, dynamics, alarm configuration) onto a customer computer while keeping the entire runtime history intact, and to re-attach that history to the freshly opened project after the upgrade.

The procedure applies to projects authored in WinCC v7.0 and migrated within the v7.x branch (v7.0, v7.2, v7.3, v7.4, v7.5). For major version jumps (e.g., v6.2 → v7.4) use WinCC Project Migrator; for same-version engineering revisions (v7.0 SP3 → v7.0 SP3 on two different computers) the manual merge procedure below is sufficient and avoids migrating segment databases that would otherwise be rebuilt empty.

2. Prerequisites

Verify the following before touching the customer PC:

• WinCC version parity. The engineering PC and the runtime PC must run the same WinCC major/minor version (e.g., both v7.0 SP3). Mismatched service packs will cause Project Migrator to refuse the file, and the binary project file (<Project>.MCP) is not forward- or backward-compatible across SPs in all cases.
• Identical licensing. The customer computer must have a WinCC RC + RT license (Runtime + Configuration). An RT-only license cannot open the project in the Graphics Designer; you will need RC activated temporarily, or you must edit the project on the engineering PC and copy the closed project file over.
• SQL Server runtime. WinCC v7.x uses Microsoft SQL Server (2005/2008/2012/2014 depending on service pack) to host the runtime database. Confirm the SQL Server service (WinCC -> SQL Server in services.msc) is running before the backup.
• Consistent computer name handling. When the project was first copied from engineering to customer, the internal computer name string was already overwritten. After update, the customer computer name must remain identical, otherwise internal computer-specific references (startup lists, server prefixes) need to be re-mapped.
• Tag name stability. The TagLogging tags, AlarmMessage tags, and User Archive field names must not be renamed between the old and new project version. If tag names changed, archive re-linking will produce orphaned or empty columns and the old data is effectively lost.
• Administrative Windows account. You need local administrator rights plus the SQL Server sysadmin role on the WinCC instance to detach/attach MDF/LDF files.

3. WinCC Project Folder Structure

A standard WinCC v7.x project directory contains the following load-bearing subfolders. Knowing which folder owns which data is essential for a partial update that keeps history alive.

4. Pre-Update Backup Procedure

Run the full backup sequence on the customer computer with WinCC Runtime stopped. Stop the project in WinCC Explorer (right-click the project → Stop Runtime) or stop the WinCC Runtime and WinCC -> SQL Server services.

1. Stop the WinCC Runtime and the SIMATIC WinCC -> SQL Server service from services.msc (or use net stop "WinCC_Project" and net stop "WinCC_SqlServer").
2. Copy the entire project folder to a timestamped backup directory on a separate drive: copy D:\WinCC\Projects\<ProjectName> E:\Backup\<ProjectName>_preUpdate_<YYYYMMDD> /E /H /K
3. Export the ArchiveManager configuration by running WinCC Archive Configurator and selecting Backup → Connect Backup. This forces a segment rollover and creates a consistent snapshot.
4. Detach the runtime database using SQL Server Management Studio (SSMS) connected to WINCC\WINCC (the default WinCC instance) — right-click <ProjectName>RT → Tasks → Detach, checking Drop Connections and Update Statistics.
5. Copy <Project>RT.mdf and <Project>RT.ldf from the SQL Server default data directory (typically C:\Program Files\Microsoft SQL Server\MSSQLxx.<instance>\MSSQL\DATA) into the backup directory.
6. Back up the Windows registry hive: reg export "HKLM\SOFTWARE\Siemens\WinCC" E:\Backup\wincc_reg_backup.reg /y
7. Record the current TagLogging segment sizes, segment times, and archive tags to a text file using the WinCC Archive Configurator Export function — this lets you diff against the new project.

5. File-by-File Update Strategy

The general rule for a same-version update is: replace what the engineer changed, preserve what the runtime accumulated. The merge is asymmetric.

5.1 Components to REPLACE from the engineering revision

• GraCS\ — All new and modified .pdl pictures, including copy-pasted pictures transferred from the engineering GraCS folder.
• Library\, PAS\, ScriptLib\ — All C-scripts, VBA macros, and project functions. Function header regeneration is typically required when global function signatures changed; the Graphics Designer prompts for this on first compile.
• Textbibliothek\ — Updated text IDs and language variants.
• <Project>.MCP — The new master project file.
• Alarm Logging configuration files (within the project database) if alarm classes, priorities, or message tags were revised — handled automatically by opening the new MCP.

5.2 Components to PRESERVE from the customer PC

• ArchiveManager\ — All TagLogging and AlarmMessage ring-buffer segments. These are the historical record.
• <Project>RT.mdf and <Project>RT.ldf — The SQL Server runtime database, containing the alarm message queue state, user archive current values, and WinCC internal data.
• UserArchives\ — Active user-archive data (if not in RT.mdf).
• Customer-side ComputerName\ settings — startup sequence, hotkey configuration, services list, redundancy partner if any.

6. Step-by-Step Update Procedure

The following is the field procedure used when an engineer delivers a new WinCC v7.0 project revision to a customer PC and the runtime history must be retained.

1. Stop runtime and SQL services on the customer computer, as in Section 4. Confirm both services show Stopped in services.msc.
2. Detach the runtime database in SSMS: WINCC\WINCC → Databases → <ProjectName>RT → Tasks → Detach.
3. Stage the engineering project. Create a new folder D:\WinCC\Update\<ProjectName>_v2 and copy the entire new engineering project (MCP, GraCS, Library, PAS, ScriptLib, Textbibliothek) into it from the engineering computer.
4. Replace the project file on the customer PC. From the staged folder, copy into the existing customer project location:

   xcopy /E /I /Y D:\WinCC\Update\<ProjectName>_v2\GraCS      D:\WinCC\Projects\<ProjectName>\GraCS
   xcopy /E /I /Y D:\WinCC\Update\<ProjectName>_v2\Library     D:\WinCC\Projects\<ProjectName>\Library
   xcopy /E /I /Y D:\WinCC\Update\<ProjectName>_v2\PAS         D:\WinCC\Projects\<ProjectName>\PAS
   xcopy /E /I /Y D:\WinCC\Update\<ProjectName>_v2\ScriptLib   D:\WinCC\Projects\<ProjectName>\ScriptLib
   xcopy /E /I /Y D:\WinCC\Update\<ProjectName>_v2\Textbibliothek D:\WinCC\Projects\<ProjectName>\Textbibliothek
   copy /Y         D:\WinCC\Update\<ProjectName>_v2\<ProjectName>.MCP  D:\WinCC\Projects\<ProjectName>\<ProjectName>.MCP

   Do NOT copy ArchiveManager, RT.mdf, or RT.ldf from the staged folder.
5. Re-attach the old runtime database. In SSMS, right-click Databases → Attach and select the preserved <Project>RT.mdf; the transaction log file (.ldf) is auto-discovered if it is in the same directory.
6. Re-link the ArchiveManager folder. Open WinCC Explorer on the customer computer and open the upgraded <Project>.MCP. The new project will detect an existing ArchiveManager and prompt to reconnect; confirm. If no prompt appears, open Tag Logging → right-click the archive tag → Properties → Archive Configuration → verify the segment storage path still points to the original ArchiveManager folder.
   If the TagLogging tag names changed, the old segments are no longer matched to the new tags. Either revert the rename or accept that the disconnected segments are unrecoverable. Always diff tag names in the Archive Configurator export between old and new revisions before merging.
7. Verify picture scripts compile. Open the Graphics Designer, load the start picture, and run Tools → Recompile All Pictures. Resolve any "Function not defined" errors by regenerating function headers (right-click the picture → Header → Reset).
8. Restart services: net start "WinCC_SqlServer" followed by net start "WinCC_Project" (or use the WinCC Service Control Applet).
9. Activate the project in WinCC Explorer and verify the runtime starts cleanly.

7. Re-Linking Historical Archives After the Update

After the new project is open and the ArchiveManager folder is in place, verify the historical continuity of each TagLogging tag and AlarmMessage class. The runtime is now writing new segments into the same folder; the old segments remain in place and are queried by the WinCC Trend Control and Alarm Control on demand.

To re-link explicitly (only needed if the re-attach was not automatic):

1. Open WinCC Explorer → Tag Logging.
2. Right-click the project node → Archive Configuration.
3. For each archive tag, confirm the Storage Location field shows the path to the original ArchiveManager folder, not a new empty path.
4. Click Connect Backup in the toolbar to merge the new tag configuration with the existing segment files. A status dialog lists the number of segments linked.

For AlarmMessage ring buffers, the same logic applies: Alarm Logging → Archive Configuration → Connect Backup. The WinCC AlarmControl view should immediately show historical messages with their original timestamps when the time range filter is widened.

8. Verification Checklist

9. Troubleshooting Matrix

10. When to Use WinCC Project Migrator Instead

The manual merge procedure above is the right tool for same-version engineering updates. For different version updates, use WinCC Project Migrator, which automates the conversion of the project file and all referenced sub-projects. Migrator is invoked from Start → Siemens Automation → WinCC → Tools → Project Migrator and steps through:

1. Selection of source project (older version) and target version.
2. Backup of the source project (mandatory — Migrator refuses to proceed without one).
3. Conversion of the MCP, the engineering database, and the runtime database schema.
4. Generation of a migration log listing all converted objects, warnings, and errors.

For installations where continuous uptime is mandatory and any update window is unacceptable, the standard Siemens recommendation is a redundant WinCC server/client pair: the standby server is updated while the primary carries runtime, then a controlled failover. This is a much larger architectural change and is typically scoped into the project from the start, not retrofitted for a single update.

11. Field-Proven Caveats

• Always work from a copy. Even with backups, do the first update on a clone of the customer PC (disk image or a test bench with the same WinCC version) before touching the live machine. The clone catches 90% of surprises (MCP version mismatch, missing DLLs, VBA reference drift) before they happen on the production system.
• Tag name parity is a hard contract. Treat the list of TagLogging and AlarmMessage tag names as an API between the engineering revision and the deployed runtime. Renames require a written migration plan: dump the old data, transform, re-import under the new name — there is no in-place rename that preserves segment history.
• Don't mix ArchiveManager folders from different projects. The folder is keyed implicitly to the project database; cross-project pasting will produce read errors and potential data corruption. Each WinCC project owns exactly one ArchiveManager.
• User archive views may need manual refresh. After re-attaching RT.mdf, User Archive table views in the Graphics Designer sometimes need to be re-opened to pick up the current row pointer; a page refresh (F5 on the active picture) is usually sufficient.
• Segment encryption keys. If the customer project uses encrypted segments (configured in Archive Manager → Properties), the key is stored in the project database. After merging, the new project picks up the existing key automatically, but on a clean re-deploy the segments will become unreadable. Always re-attach before opening the new MCP for the first time when encryption is enabled.

12. References Used in This Procedure

For the official Siemens FAQ on data backup of WinCC projects (TagLogging, Alarm Logging, and project databases), see entry 29488044 in the Siemens Industry Online Support: Siemens Industry Online Support entry search. The same article documents which files belong to a complete backup and the recommended order for restoring from backup.

For project versioning and migration beyond the v7.0 to v7.x path, consult the WinCC V7.x documentation set on the same portal, in particular the WinCC Information System chapters on Project Administration and WinCC Project Migrator.