WinCC V5.x Runtime Database Delete RT Messages and Fix Time

1. Overview: WinCC V5.x Runtime Database Architecture

SIMATIC WinCC V5.x (including V5.0 SP2) stores all process values, alarms, and audit information in a Sybase SQL Anywhere (Adaptive Server Anywhere) database named projectRT.db. This file is created in the project runtime directory (typically <ProjectPath>\<ComputerName>\) at first activation and grows continuously during operation. The runtime database serves two principal subsystems:

• Alarm Logging Runtime – short-term and long-term message archives (MSArcShort, MSArcLong)
• Tag Logging Runtime – process value archives (TLGShort, TLGLong, plus configured archive tables)

Unlike the configuration database (project.mdf), the runtime database is intentionally mutable and designed to be queried, segmented, and backed up while WinCC Runtime is active. Editing it without understanding its structure, however, risks corrupting the entire project – analogous to editing the Windows registry or, as one engineer put it, "someone cutting open your stomach." The procedures below are for engineers who already operate the WinCC system and need to perform controlled, justified maintenance of projectRT.db.

2. Symptom Catalog: Three Common projectRT.db Issues

3. Root Cause Analysis: Erroneous 2032/2010 Date Stamps

A very common field fault on a freshly commissioned WinCC V5.0 SP2 system is an alarm list populated the moment Runtime starts with messages stamped with an obviously wrong year – typically 2032, 2010, 1980, or 1970. This is not a WinCC bug. The cause is almost always on the PLC side.

3.1 S7-CPU Date/Time Origin

WinCC reads the time from the AS (Automation Station) in two ways:

1. Time-of-day synchronization via the WinCC time master – WinCC broadcasts its local clock to all configured S7 connections at a configurable interval (default 10 s in the "Time Synchronization" editor of the WinCC Explorer).
2. Time stamps in the message buffer of the S7-CPU – When a bit-triggered message (e.g., MSG_LOCK, MSG_ACK,

   MSG_NACK) is generated, the CPU stamps the event with its internal real-time clock. WinCC then polls or receives this stamp and displays it in the Alarm Control.

If the CPU's real-time clock has never been set (factory-new module, dead backup battery, or STOP → RUN transition with no time master), the CPU returns either:

• 90-01-01 00:00:00 (S7-300/400 default = 1990-01-01, but partial-BCD yields year 1990, 1980, or 2032 depending on the byte that was read)
• A wrapped value such as 32-12-31 23:59:59 interpreted by WinCC as 2032
• 0 (interpreted by WinCC as 1970-01-01 on Unix-derived time bases)

The classic 2032 value is the classic BCD wrap: the high nibble of the year BCD byte becomes 3 and the low nibble becomes 2, yielding 0x32 = 32 decimal, which WinCC renders as 2032 (assuming 2000-base). The 2010 value is the typical "year never set, returned as default" pattern from a S7-300 CPU that was never synchronized.

3.2 Verify on the CPU

1. Open STEP 7 (V5.x) → online → PLC → Set Time of Day and read the current CPU clock.
2. If the time is 01.01.1990 00:00:00 or similar, the CPU has never been synchronized.
3. Check the backup battery LED on the CPU – if the battery is dead, the clock is lost on every power cycle.
4. Check the OB82 / OB122 / OB100 diagnostics: a clock fault generates diagnostic interrupt 0x0122.

Siemens' official guidance for this scenario is captured in Entry ID 8795809 – search the Siemens Industry Online Support for "WinCC V5 incorrect date in alarm list" or "2032" to retrieve it.

4. Solution: Time Synchronization Procedure for S7 + WinCC V5.x

4.1 Configure the WinCC Time Master

1. In WinCC Explorer, right-click "Time Synchronization" → Open.
2. Select the WinCC server that owns the master clock (typically Server 1, the preferred server in a redundant pair).
3. Check "Use the time of the following connection as master clock" and select the S7 connection name used for the time master.
4. Set the access point (default 1 = local, 2 = LAN). For redundant systems set access point 2.
5. Set the synchronization interval to 10 s (default) – every 10 seconds WinCC writes its clock to the S7-CPU area OB1 / SFC 0 SET_CLK (or for S7-300/400, via SFC 0 / SFC 1).
6. Restart the WinCC Runtime.

4.2 Verify Time Stamps

1. In WinCC Explorer → Alarm Logging → open the Alarm Control in graphics designer.
2. Trigger a known bit in the PLC (e.g., set M100.0).
3. Confirm the new event shows today's actual year, not 2032 or 2010.

4.3 Clear the Faulty Historical Entries

Even after time synchronization is fixed, the bad 2032/2010 entries remain in MSArcShort / MSArcLong. Remove them using the SQL procedure in §6 below, or archive the project and rotate the database.

5. The projectRT.db Schema: What You Can (and Cannot) Edit

The default WinCC V5.x runtime database ships with the following critical tables:

The Sybase SQL Anywhere reference manual is installed locally with WinCC at C:\Program Files\Sybase\SQLAnywhere\win32\ (path may vary by locale and Windows version). Open html_docs\index.html for the full command set. Useful statements for the engineer are summarized in §6.

6. Procedure: Deleting Individual Entries from MSArcShort / MSArcLong

6.1 Prerequisites

• Backup projectRT.db to a separate folder. The file is locked while Runtime is active, so stop the SCRIPT.exe and Alarm Logging service first, or use the WinCC Project Duplicator / Segment Archiver to make a consistent copy.
• Install the Sybase Interactive SQL utility (dbisql.exe or dbisqlc.exe), shipped with WinCC in the same SQLAnywhere\win32 directory.
• Identify the table column names. The most important columns in MSArcLong are:

6.2 Connect with dbisql

1. Start → Programs → Sybase SQL Anywhere → Interactive SQL.
2. From the menu: Connection → Connect.
3. User ID: dba | Password: sql (default WinCC Sybase credentials).
4. Database: <ProjectPath>\<ComputerName>\projectRT.db
5. Click OK. You are now connected to the live WinCC runtime database – proceed with caution.

6.3 Inspect Before You Delete

Run a read-only SELECT first. Never run DELETE on a table you have not verified:

SELECT MsgNr, State, TimeChange, MsgText
FROM MSArcLong
WHERE TimeChange < '2032-01-01'
ORDER BY TimeChange DESC;

This will return every record stamped with the impossible year 2032 (or any other impossible date). Confirm the row count matches your expectation before issuing the DELETE.

6.4 Delete Faulty Records

DELETE FROM MSArcLong
WHERE TimeChange < '2032-01-01';\code>
For a short-term archive, substitute MSArcShort

DELETE FROM MS_State
WHERE MsgNr IN (SELECT MsgNr FROM MSArcLong WHERE TimeChange < '2032-01-01');

For a complete purge of all archives after a known date, use:

DELETE FROM MSArcLong WHERE TimeChange < '2010-06-01';
DELETE FROM MSArcShort WHERE TimeChange < '2010-06-01';
DELETE FROM MS_State WHERE MsgNr NOT IN (SELECT MsgNr FROM MSArcLong);

6.5 Commit and Verify

COMMIT;
SELECT COUNT(*) AS Remaining FROM MSArcLong;
SELECT COUNT(*) AS Remaining FROM MSArcShort;

Close dbisql. Restart the WinCC Runtime. The Alarm Control should now show only correctly stamped events.

7. Symptom: Erratic Archive Update Behavior on Redundant Servers

Field reports frequently describe the following: "On Server 1 the database seems to refresh every 5–10 days; on Server 2 the same database is updated continuously." This is not a database bug. It is a mismatch in archive configuration between the redundant pair.

7.1 Why This Happens

WinCC V5.x redundancy is configured at the project level, but each server independently runs its own Alarm Logging Runtime and Tag Logging Runtime against its own copy of projectRT.db. The archive parameters – segment size, segment count, archive cycle – are stored in the project, but the actual file rotation is driven locally on each machine. If the two servers were configured separately (e.g., one was rebuilt and the archive editor was not re-opened) the archive cycles diverge.

7.2 Resolution Procedure

1. On both servers, open WinCC Explorer → Alarm Logging → right-click the archive → Properties (or Configuration).
2. Compare the Archive Cycle, Segment Time, and Number of Segments fields. All three must be identical on both servers.
3. Compare the equivalent fields in Tag Logging for every archive configured.
4. If a divergence is found, apply the same value on both servers, save, and re-deploy the project (drag from the project root onto the target server in the WinCC Explorer).
5. Restart Runtime on both servers in the correct order: preferred server first, then standby server.

7.3 Expected Behavior After Correction

• Both servers write to projectRT.db continuously at the configured tag logging acquisition cycle (typically 500 ms – 1 s for fast tags, 1 s – 1 min for slow tags).
• Archive segments rotate on the boundary defined by the archive cycle. If the cycle is "1 day" both servers create a new segment file at 00:00 local time.
• Under runtime, the standby server mirrors the preferred server's archive state, but the local archive still grows in parallel – this is by design for fail-over forensics.

8. Backup and Recovery Strategy for projectRT.db

Because the runtime database is the single source of truth for everything the operator sees, the backup strategy is critical. A field-proven approach is:

1. Scheduled segment export – WinCC's Alarm Logging and Tag Logging editors include a "Connect backup" feature. Set the export path to a network share and the cycle to daily.
2. Hourly .db snapshot – use Windows Task Scheduler to call dbbackup.exe -c "UID=dba;PWD=sql;DBF=<ProjectPath>\<ComputerName>\projectRT.db" <BackupPath>\projectRT_%date%.db at low-traffic hours (e.g., 02:00).
3. Pre-edit snapshot – before any manual SQL operation (per §6), copy projectRT.db to projectRT_preedit_yyyymmdd.db. This is the only rollback path if the SQL statement corrupts the database.

9. Commissioning Checklist: Time and Database Health

10. Troubleshooting Matrix: projectRT.db Field Faults

11. Frequently Asked Questions