Troubleshooting Incomplete Alarm Message Compilation Across Multiple Controllers in PCS 7

When SIMATIC PCS 7 fails to compile AS messages consistently into WinCC Alarm Logging across multiple controllers after a system migration, the failure is caused by corrupted message server connection caches ('asasrv.ini') or non-unique message number assignments in STEP 7. To resolve this, ensure all AS projects use 'Always assign CPU-oriented unique message numbers' under Message Number Assignment in STEP 7, delete stale compilation caches ('asasrv.ini' and temporary WinCC SQL project scratch tables), and execute a full OS compilation with 'Entire OS' and 'With memory reset' selected.

Executive Summary

In multi-controller SIMATIC PCS 7 systems migrated from older releases (such as PCS 7 V7.1 to V9.0 SP1), engineers often encounter an issue where the OS compile process intermittently omits alarm messages. Block icons on graphics screens display active alarm colors correctly, but the corresponding alarm lines never appear in the WinCC Alarm Logging runtime list. Furthermore, the compilation behavior shifts between runs: one compile processes AS1 while skipping AS2, and the next compile reverses the behavior. This article diagnoses the root causes—including message server index fragmentation and project-oriented message collisions—and provides a definitive resolution procedure.

Architectural and System Mechanics

AS-OS Message Compilation Architecture in SIMATIC PCS 7:

STEP 7 Message Number Assignment:
Project-oriented message numbers (Legacy V7.x): Message numbers were unique only within an individual AS project, frequently colliding when multiple controllers compiled into a single OS Server.
CPU-oriented unique message numbers (Modern V8/V9): Guarantees globally unique message IDs per CPU across the entire multiproject.
AS-OS Compilation Service (asasrv.exe):
Acts as the bridge between STEP 7 CFC message attributes and the WinCC CS SQL Server database.
Caches intermediate mapping tables in asasrv.ini and project scratch directories. If migrated database schemas contain orphaned connection GUIDs, the service aborts compilation threads silently for specific controllers.
WinCC Alarm Logging Integration:
Messages compiled from CFC blocks (Alarm_8P, MsgEvId) are written directly to the WinCC configuration database (*.mdf). Corrupt index tables cause SQL write collisions during parallel multi-controller processing.

Step-by-Step Engineering and Implementation Procedure

Step 1: Enforce CPU-Oriented Unique Message Numbers Across All Controllers

In SIMATIC Manager, select the Multiproject root.
For each AS project: Select the project root -> 'Options' -> 'Assign Message Numbers...'.
Select 'Always assign CPU-oriented unique message numbers' and confirm assignment.
Recompile all CFC charts on all controllers (CFC -> 'Compile' -> 'Entire Program').

Step 2: Purge Stale OS Compilation Caches

Close WinCC Explorer on the Engineering Station and remote OS Servers.
Navigate to the WinCC OS project folder on disk.
Delete the compilation cache file asasrv.ini.
Delete temporary log files ending in .dmp and .log in the project root.

Step 3: Reset the WinCC Database Indices Using CCResetOS

Open Command Prompt as administrator.
Navigate to C:/Program Files (x86)/Siemens/WinCC/bin/.
Run CCResetOS.exe to detach stale database handles and reset SQL connection pooling.

Step 4: Execute a Clean Full OS Compilation

In SIMATIC Manager, right-click the OS Server object -> 'Compile'.
Select ALL automation stations connected to this OS Server.
In the compile scope dialog, select 'Entire OS' and check 'With memory reset'.
Proceed with compilation; verify that the compile log reports 0 errors across all controllers.

Verification

To verify complete alarm compilation:
1. Open WinCC Explorer on the OS project -> 'Alarm Logging'.
2. Inspect the 'AS Messages' folder; verify that message entries from all controllers are present.
3. Start WinCC Graphics Runtime; trigger test alarms on each controller.
4. Verify that alarms from every controller appear immediately in the WinCC Alarm Control alarm banner with correct timestamps and message texts.

Limitations and Operational Precautions

Operational precautions:
- Executing an OS compile 'With memory reset' requires a full download to the OS Server; delta download is not possible following a memory reset compile.
- Ensure no other engineers have WinCC Explorer or CFC charts open during full compilation to prevent file lock errors.
- Switching from project-oriented to CPU-oriented message numbers requires recompiling and downloading all AS programs.

Engineer FAQ

Q: Why did alarms show on block icons but not in Alarm Logging?

A: APL block icons evaluate dynamic status words directly via WinCC tags, whereas Alarm Logging relies on the compiled message server database entries.

Q: What does `asasrv.ini` do?

A: It stores temporary compiler state and cache mappings for the AS-OS compilation engine.

Q: Is CPU-oriented unique message numbering mandatory in PCS 7?

A: Yes, for reliable multi-controller operation in PCS 7 V8.x and V9.x, CPU-oriented unique message numbering is strictly required.

Q: Does deleting `asasrv.ini` harm the project?

A: No. The compilation engine regenerates a clean asasrv.ini automatically during the next OS compile.

Q: Why did the compile skip different PLCs on each attempt?

A: Database lock contention in the WinCC SQL database caused compilation threads to timeout intermittently on arbitrary controllers.

Technical References

Related Tags

OS Compilation, Alarm Logging, AS Messages, asasrv.ini, Message Numbering

20 respuestas

Troubleshooting Incomplete Alarm Message Compilation Across Multiple Controllers in PCS 7