C135 PCS 7 (PCS7)
6C
6 Cielo Ciencia y Tecnología
·Publicada en C135 PCS 7 (PCS7)

How to Fix Missing Active Alarm Texts and Identical Startup Timestamps in PCS 7 WinCC Alarm Logging

How to Fix Missing Active Alarm Texts and Identical Startup Timestamps in PCS 7 WinCC Alarm Logging

Missing alarm texts in the active alarm list combined with alarms appearing only in the acknowledged list bearing identical project activation timestamps indicates database desynchronization in WinCC Alarm Logging or a corrupted runtime message buffer. When the message server cannot match incoming ALARM_8P event IDs to local text definitions, the display remains blank until runtime restarts, at which point buffered events are stamped with the restart time. The issue is resolved by deleting orphaned runtime cache files, resetting Alarm Logging archives, and performing an 'Entire OS' compilation with memory reset.

Table of Contents

Symptom Analysis and Failure Mechanism

In SIMATIC PCS 7 systems (such as V7.0 SP2, V8.x, and V9.x), engineers occasionally encounter a critical alarm processing malfunction where process alarms generated by the AS (via ALARM_8P, NOTIFY_8P, or technological block EventState) exhibit the following behavior:
1. Active Alarm List Failure: When a real process fault triggers in the controller, the alarm line in the WinCC AlarmControl banner or alarm page appears completely blank, displays missing text blocks, or fails to appear entirely in the active alarm list.
2. Behavior on Runtime Restart: When the WinCC Runtime project is deactivated and reactivated, the missing alarms suddenly appear in the Acknowledged List (or alarm log view), but all entries exhibit identical timestamps corresponding exactly to the minute and second the WinCC project was restarted.

Failure Mechanisms

This anomaly stems from two interconnected failures within the WinCC alarm subsystem:
* Message Configuration Desynchronization: WinCC Alarm Logging maintains an internal database mapping 32-bit message numbers to message texts, process value formatting strings, and message classes. If an online delta compile was interrupted or if text library pointers became desynchronized, the runtime message server (CCAlgRtServer.exe) receives raw message telegrams from the S7 Message Server but fails to resolve text strings, suppressing the display.
* Corrupted Runtime Message Journal and Cache: During shutdown or communication disruptions, unresolved message events remain trapped in the transient memory cache (.dcf / SQL transaction logs). Upon reactivation, the runtime engine flushes these unconfirmed states to the acknowledged table and defaults the event timestamp to the current local activation clock because the original AS high-resolution time header was invalid or unparsed.

Message Processing Flow from AS to WinCC AlarmControl

Process alarms in PCS 7 rely on an event-driven mechanism coordinated between controller blocks and the HMI server:
1. Controller Detection: A CFC block (e.g., MonAnL, MotL) detects an abnormal condition and triggers an embedded ALARM_8P (FB19) call.
2. Time Stamping: The CPU operating system stamps the event with UTC time (from the CPU system clock or high-resolution CP clock with 1 ms accuracy).
3. Telegram Dispatch: The CPU sends an S7 alarm telegram containing the Message Number, Event State (Incoming/Outgoing), and Associated Process Values across the Plant Bus.
4. OS Reception: WinCC S7 Protocol Suite (s7chn.chn) passes the telegram to CCAlgRtServer.exe.
5. Database Lookup: CCAlgRtServer queries the SQL Alarm Logging configuration table for text strings corresponding to the Message Number.
6. Display: The merged alarm record is displayed in the WinCC AlarmControl OCX in @AlarmActive.pdl.

Step-by-Step Recovery and Reset Procedure

To resolve missing alarm texts and restore proper time-stamped alarm logging, perform the following recovery steps:

Step 1: Deactivate WinCC Runtime

  1. On the affected OS Server or Single Station, deactivate WinCC Runtime via WinCC Explorer.
  2. Close WinCC Explorer and ensure all background processes (CCAlgRtServer.exe, Pcs7AlarmRtHost.exe, CCTlgServer.exe) terminate cleanly in Windows Task Manager.

Step 2: Clear Corrupted Project Caches

  1. Navigate to the project directory on the OS computer (e.g., D:\Projects\OS_Project_Prj).
  2. Delete the temporary database connection file: <ProjectName>.dcf. WinCC will automatically regenerate this file from SQL Server upon project load.
  3. Open the subfolder ArchiveManager\AlarmLogging and verify whether orphaned transaction log files (.ldf) or locked .mdf segments are present.

Step 3: Reset Alarm Logging Configuration via OS Compile

  1. On the Engineering Station, open SIMATIC Manager.
  2. Select the OS component, right-click, and select Compile.
  3. In the wizard, select the network connection and choose Entire OS.
  4. Check the box 'With memory reset'. This forces SIMATIC Manager to wipe the target OS message table definitions and perform a fresh, contiguous export of all ALARM_8P message identifiers, classes, and text strings.
  5. Execute the compilation to completion.

Step 4: Verify SIMATIC Time Synchronization

Ensure the CPU and OS share a unified time source to prevent timestamp overriding:
1. Open HW Config for the AS CPU and verify that Time Synchronization is enabled on the Plant Bus subnet (as slave to a master SICLOCK or NTP time server).
2. In WinCC Explorer, open Time Synchronization and ensure the OS is configured to synchronize via the terminal or plant bus.

Alarm Subsystem Parameter and Diagnostic Reference

The following table outlines key parameters and tools used to diagnose and resolve WinCC Alarm Logging failures:

Component / UtilityLocation / CommandPrimary FunctionFault Indicator / Recovery ActionCCAlgRtServer.exeWinCC \bin folderRuntime alarm processing and bufferingHigh CPU or crash; restart WinCC and purge .dcfWinCC Alarm LoggingWinCC Explorer EditorConfiguration of message classes and textsEmpty message list; execute OS compile with memory reset<Project>.dcfRoot OS Project DirectoryDatabase connection cache fileCorrupt pointers; delete while runtime is deactivatedapdiag.exeWinCC \bin\apdiag.exeDiagnostic console and trace outputCheck for 'AlmRtServer: message ID not found' errorsSIMATIC Time SyncWinCC Explorer EditorSynchronizes OS time with AS clockIdentical restart timestamps; configure NTP/SICLOCK master

Ensure that all redundant servers receive an identical compile to preserve alarm synchronization.

Verification

To verify that alarm logging has been restored to normal operation:
1. Activate WinCC Runtime on the OS Server.
2. Open the standard alarm screen (@AlarmActive.pdl).
3. In CFC Editor, force a test alarm condition on a monitored block (e.g., invert an interlock or exceed an analog threshold on a simulated block).
4. Verify that the alarm appears immediately in the Active Alarm List with complete message text, plant area, and tag identification.
5. Verify that the timestamp matches the exact time of occurrence (accurate to milliseconds) rather than the project startup time.
6. Acknowledge and clear the fault, verifying proper transition to the Acknowledged and Outgoing lists.

Limitations and Operational Precautions

  • Performing an OS Compile with 'With memory reset' requires deactivating WinCC Runtime on single-station systems; in redundant pairs, follow the sequential redundant download procedure.
  • Never manually delete active SQL archive segments (.mdf/.ldf) while WinCC Runtime is active, as this corrupts the SQL Server database attachment.
  • If multi-language projects are configured, verify that alarm texts are populated in the currently active runtime language in the Text Library.
  • Timestamp discrepancies between AS and OS will cause alarms to appear out of order or trigger buffer warnings in CCAlgRtServer.

Engineer FAQ

Why did alarms show the project activation timestamp instead of the event time?

When the alarm engine cannot parse the time telegram from the controller or when buffered events lose their time header during an ungraceful shutdown, WinCC substitutes the local computer system clock at the moment the message server initializes.

Does 'With memory reset' during OS compile delete historical alarm archives?

No. 'With memory reset' clears and rebuilds the message configuration tables (message definitions, texts, and classes). Historical alarm logs stored in ArchiveManager remain intact unless explicitly detached.

Can missing alarm texts be caused by Windows regional settings?

Yes. If the runtime language does not match the language in which the project was compiled in SIMATIC Manager (e.g., German vs English US), message text fields will appear blank.

Technical References

Related Articles

Related Tags

  • Alarm_Logging
  • WinCC_Runtime
  • ALARM_8P
  • Time_Synchronization
  • PCS7_V7_0
6 respuestas