WinCC Process Alarm Timestamp Shows 1995: Root Cause and Fix

Problem Statement

Operators report that one or more process alarms in WinCC Alarm Logging display a date stamp of 01.01.1995 (or any date in calendar year 1995) while every other alarm list — message, operator, system, and archive views — shows the correct current date and time. The fault is reproducible, persists across HMI restarts, and is independent of the operator station's local time zone or locale setting. Because the year 1995 is not coincidentally chosen but is the Siemens SIMATIC epoch for many internal time formats, the symptom almost always points to an uninitialized or incorrectly initialized timestamp on the PLC side that is then transported to the HMI via the process-alarm telegram.

This article documents the alarm-timestamp architecture in WinCC Runtime Professional and WinCC V7, isolates the root cause to the PLC function block that builds the time stamp for the alarm message, and provides three concrete resolution paths: full time-of-day synchronization between PLC and WinCC stations, manual CPU clock adjustment via HW Config, and PLC-side correction of the alarm-generation function block.

Alarm Timestamp Architecture in WinCC

WinCC Alarm Logging distinguishes between two alarm categories whose timestamps originate at different points in the system:

When a process alarm is triggered by a bit transition or value threshold on the AS, the corresponding ALARM_S / ALARM_8 / ALARM_SQ / NOTIFY function block stamps the time of the event using its own internal time variable (typically TIME_OF_DAY / DT / DTL) and packages it into the alarm telegram. WinCC Alarm Logging, on receiving the telegram, displays the timestamp that came from the PLC — it does not overwrite it with the HMI's local time-of-day. This is why a misconfigured PLC timestamp appears in the operator view even when every other WinCC subsystem shows the correct clock.

Reference: see the WinCC Engineering System manual under "Time synchronization in WinCC" — Siemens Support entry 109754984.

Why 1995: The SIMATIC Epoch

SIMATIC controllers internally represent time spans in IEC 61131-3 TIME format, which uses 32-bit signed milliseconds with the epoch fixed at 00:00:00 on 01 January 1995. The related DATE_AND_TIME (DT) BCD-encoded format and the TIA Portal DTL structure are also structured around the same 1995-01-01 base. When a timestamp variable is not properly initialized — for example, after a CPU cold restart, a STOP-to-RUN transition without OB100 initialization, a load of a fresh project to the PLC, or a corrupted retain area — the variable evaluates to zero, which decodes to DT#1995-01-01-00:00:00.

The 1995 date appearing in WinCC Alarm Logging is therefore a direct visualization of an uninitialized SIMATIC time variable being interpreted by the HMI as the moment of the alarm event.

Root Cause Analysis

The root cause is almost always PLC-side. Common contributing factors, ordered by frequency:

1. Function block not initialized on cold restart. ALARM_S / ALARM_8 / ALARM_8P blocks require the EN / ACK / EV_ID / SIG / SD / SP inputs to be wired. If the block is invoked with default values (all FALSE, EV_ID=0, SD=DT#1995-01-01-00:00:00), the alarm telegram still leaves the CPU but with an undefined timestamp.
2. OB100 / OB101 missing. A warm restart after power-cycle that does not pass through OB100 (S7-300/400) or does not initialize the alarm block instance DBs on startup leaves DTL / DT tags at zero.
3. CPU clock never set. If the PLC battery is removed for more than the buffer time, the internal RTC loses its time. On a subsequent warm restart the RTC reads DT#1995-01-01-00:00:00 until a sync or manual set occurs.
4. Wrong interpretation of SFC1 / SFC0. The PLC user is reading SFC1 READ_CLK into a non-initialized DT tag in the wrong order of bytes; the result is sent verbatim into the alarm telegram.
5. Synchronization disabled. The PC station's "Set time on PC station" service or the PLC's "Set time on AS" mechanism is disabled, so even when the HMI has the right clock the PLC is unaware of it.
6. Multiple PLCs, one not synchronized. Process alarms from a secondary PLC that has not been added to the WinCC time-master scheme still show the local default.

Solution A — Time Synchronization Across PLC and WinCC

The recommended permanent fix is to enable time-of-day synchronization so that the PLC clock cannot drift or default to 1995 unnoticed. Siemens supports several synchronization paths; pick the one that matches your hardware topology.

A1. PLC as time master, HMI as slave

1. On the WinCC station, open the "Computer Properties" → "Time Synchronization" dialog (WinCC V7) or "Runtime settings" → "Time synchronization" (TIA Portal).
2. Select the S7-300/400/1200/1500 PLC as the time master.
3. Choose "Slave: Set time on station via the master".
4. Configure the synchronization interval. A value of 10 minutes is typical for SCADA networks; reduce to 1 minute on tightly time-correlated alarm logging projects.
5. Confirm the WinCC service "SIMATIC Time Service" is running (it is installed by default with WinCC).

A2. WinCC station as NTP master, PLCs as NTP slaves

1. Configure the PC's NTP server (or use the WinCC "Time Service" to act as NTP server) on UDP port 123.
2. In the PLC hardware configuration (HW Config / TIA Portal device view), open the CPU properties → "Time of day" tab.
3. Enable "Synchronization via NTP", enter the WinCC station's IP address, and set the synchronization interval (recommended 60 seconds).
4. Activate the configuration and download to the PLC.

A3. Central NTP server for both

For multi-cell plants with several PLCs and OS servers, point both the WinCC Time Service and every PLC's NTP client at a single GPS-synchronized NTP appliance. This eliminates drift and removes 1995-stamp risk across the whole fleet.

Reference: see the WinCC Engineering System manual, chapter "Time Synchronization" — Siemens Support entry 109754984.

Solution B — Manual CPU Clock Adjustment via HW Config

If time synchronization is not yet commissioned and the operator needs an immediate remediation, the CPU clock can be set manually:

1. Open the SIMATIC Manager (S7-300/400) or TIA Portal project containing the affected station.
2. In the project tree, double-click the station icon to open HW Config (or in TIA Portal open the "Devices & networks" editor and select the CPU).
3. Right-click the CPU and choose PLC → Set Time of Day (SIMATIC Manager) or use the "Online & Diagnostics" panel → "Set time of day" (TIA Portal).
4. In the dialog, click Set Time of Day; the current PC clock is written to the PLC's RTC.
5. Verify with the same dialog using Read Time of Day.

Solution C — PLC-Side Correction of the Alarm FB

The most robust engineering fix is to ensure the alarm function block always has a valid timestamp source. Below is the canonical pattern in both STEP 7 V5.x and TIA Portal SCL.

STEP 7 V5.x — ALARM_8P with explicit timestamp wiring

FUNCTION_BLOCK FB_ProcessAlarm
VAR
    sLastTime   : DATE_AND_TIME;  // last event time
    bTrigger    : BOOL;           // rising edge = new alarm
END_VAR
BEGIN
    // Read the current PLC clock every scan and store it.
    // Avoid using uninitialized DT variables.
    sLastTime := DWORD_TO_DT(RD_SYS_T(&ret_val := wRetVal));

    IF bTrigger THEN
        // ALARM_8P sends 8 binary alarms with a timestamp.
        // SIG[1..8] are the inputs; SD_1 is the user-supplied timestamp.
        // Force SD_1 to the freshly read clock.
        ALARM_8P_1(
            EN     := TRUE,
            EV_ID  := DW#16#1001,
            SIG_1  := bTrigger,
            SIG_2  := FALSE,
            SIG_3  := FALSE,
            SIG_4  := FALSE,
            SIG_5  := FALSE,
            SIG_6  := FALSE,
            SIG_7  := FALSE,
            SIG_8  := FALSE,
            SD_1   := sLastTime,
            ACK    := bAckIn,
            ...
        );
    END_IF;
END_FUNCTION_BLOCK

TIA Portal SCL — NOTIFY_8P with DTL timestamp

#region AlarmTimestampInit
// Initialise timestamp instance DB on cold restart to avoid 1995 default
IF "FirstScan" THEN
    #statDTLTimestamp := DTL#1995-01-01-00:00:00.0;  // intentionally 1995
    #statDTLTimestamp := DTL_FROM_TIMESTAMP(TIMESTAMP := IEC_TIMESTAMP());
    "FirstScan" := FALSE;
END_IF;
#endregion

// Build the alarm telegram with a validated timestamp
"instNOTIFY8P"(SIG_1 := bAlarmCondition,
               SIG_2 := FALSE,
               SD_1  := #statDTLTimestamp,    // never uninitialized
               EV_ID := 16#0001_0001);

Key initialization rules

• Always populate the timestamp input (SD / SD_1..SD_8) with a value derived from a system clock read, never from a DB variable that may be zero on first scan.
• Call RD_SYS_T / SFC1 on every cycle or once per event; never rely on the variable retaining a value across OB100 restart boundaries unless it is in a non-volatile DB.
• If the program structure uses a multi-instance DB, ensure that DB is loaded with the same snapshot the rest of the program uses — otherwise instances may reset independently of the parent OB.
• Add an OB100 / startup OB that explicitly initializes every alarm-tag DT / DTL variable to DTL_FROM_TIMESTAMP(IEC_TIMESTAMP()) on warm restart. This protects against RTC buffer failure on long power-downs.

Archive Continuity Considerations

Alarms that have already been archived with a 1995 timestamp remain in the alarm database with that value. WinCC Alarm Logging does not re-stamp on read. Three options for the historical data:

Verification and Commissioning Steps

After applying Solution A, B, or C, verify the fix end-to-end:

1. Force a test process alarm on the PLC by toggling a bit wired to SIG_1 of the alarm block. Use the same EV_ID that was showing 1995.
2. In WinCC Alarm Logging (online), confirm the new alarm entry shows the current date and time, not 01.01.1995.
3. From the WinCC station, run w32tm /monitor /computers:<plc-ip> (for NTP-synchronized PLCs) and check the offset. Drift should be sub-second.
4. Cycle the PLC through STOP → RUN to confirm OB100 initialization still yields a valid timestamp.
5. Remove PLC backup battery for 5 minutes, restore power, observe the first alarm event after restart. With Solution A active it should be re-synchronized within one interval.
6. Repeat on every PLC in the project if multi-CPU. The fault frequently appears only on a subset of stations.

Related Issues and Cross-Platform Notes

The "1995" date specifically applies to SIMATIC. Other controllers have their own epoch defaults that can mask as the same symptom:

For alarm-system architectures, independent academic research has shown that delays between event and operator-visible alarm can be caused by network latency, bad implementation, sensor failure, and data loss — see the survey on expected detection delays for alarm systems (ScienceDirect / Adnan 2011). While the paper focuses on latency, the implementation-defect category includes the uninitialized-timestamp defect covered here, which silently corrupts the time-series data the alarm system is built upon.

Preventive Checklist for New Projects

To prevent the 1995-stamp defect from recurring in commissioning:

• Always include an OB100 / startup OB that initializes alarm FB instance DBs with the current PLC clock.
• Always wire SD_1..SD_8 of ALARM_8P / NOTIFY_8P blocks with a fresh read of SFC1 / RD_SYS_T rather than a static DB variable.
• Enable WinCC time-of-day synchronization in the project template so every cell inherits it.
• Add a loopback alarm in the standard library that fires once per shift; if it shows 1995, the synchronization has broken.
• During SAT / FAT, cycle the PLC battery or set the CPU to factory defaults to confirm the fallback path produces valid timestamps, not 1995.

FAQ