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

Demystifying the .EventState Tag and Group Display Hierarchy in SIMATIC PCS 7 WinCC

Demystifying the .EventState Tag and Group Display Hierarchy in SIMATIC PCS 7 WinCC

In SIMATIC PCS 7 WinCC, the .EventState tag is a standardized 32-bit DWORD structure tag generated automatically for technological blocks supporting chronological messaging (such as MotL, VlvL, MonAnL). It consolidates active alarm classes, unacknowledged states, and suppression flags into a single bitmask, directly feeding the Group Value property of WinCC Group Displays (@GroupDisplay). Manually forcing static bit values (2^0 to 2^31) fails to reproduce standard operating states because Group Displays decode bits according to PCS 7 Alarm Logging message classes. Bits 0-15 represent active alarm types (Alarm, Warning, Tolerance), while bits 16-31 represent unacknowledged flashing states.

Table of Contents

Executive Summary

In continuous process automation, operators navigating multi-screen WinCC supervisory environments rely on Group Displays (@GroupDisplay) embedded in overview picture hierarchies to identify alarms occurring deep within unit sub-screens. At the heart of this hierarchical annunciation is the .EventState tag—a standardized 32-bit integer generated for every technological block in the S7 program. Automation engineers attempting to reverse-engineer or simulate alarm behaviors frequently sever the live controller connection and manually force static bit patterns (from $2^0$ to $2^{31}$) into .EventState, only to discover that the graphic icons display erratic alarm symbols or fail to show 'normal' operational states. Understanding how WinCC Alarm Logging maps message classes and acknowledgment flags into the .EventState bitmask resolves this confusion.

The Role of .EventState in Hierarchical Group Alarm Annunciation

The .EventState tag is the communication bridge between AS alarm blocks and OS graphic displays:

  • Automatic Generation: Generated during AS-OS compilation for any CFC block utilizing chronological alarm messaging (ALARM_8P / MsgEvId).
  • Group Display Binding: Bound directly to the Group Value property of block icons (@PG_*.pdl) and picture tree overview hierarchy nodes.
  • Hierarchical Bubbling: Alarms propagate upwards through the Plant Hierarchy: if an instrument in an inner sub-picture alarms, its .EventState bit rolls up into the area overview button, turning the navigation header red.

32-Bit Structure and Bitmask Mapping of .EventState

The 32 bits of .EventState are partitioned into functional octets:

  • Lower Word (Bits 0 - 15) - Active Alarm States: Each bit reflects an active process event category:

  • Bit 0: Alarm High (AH)

  • Bit 1: Alarm Low (AL)
  • Bit 2: Warning High (WH)
  • Bit 3: Warning Low (WL)
  • Bit 4: Tolerance High/Low (TH/TL)
  • Bit 5: AS Operating Message
  • Bit 6: OS Operator Input Prompt
  • Bit 7: System Fault
  • Upper Word (Bits 16 - 31) - Acknowledgment & Flashing: Represents unacknowledged states. For example, Bit 16 is the unacknowledged flag for Alarm High; while Bit 0 AND Bit 16 are high, the graphic icon flashes red. When acknowledged, Bit 16 drops to 0, leaving steady red.

Chronological Messaging Architecture vs Bit Alarm Procedures

Group Displays function correctly only under standard prerequisites:

  • Chronological Messaging: In PCS 7, alarms are generated at the controller level with millisecond timestamps and passed as structured events. This populates .EventState natively.
  • Alarm Logging Prerequisite: The Group Display reads its visual formatting (colors, flash frequency, text) from the message classes configured in WinCC Alarm Logging. If Alarm Logging is inactive or OS Project Editor has not initialized the project, Group Displays cannot evaluate forced bit values.

EventState Bit Allocation and Group Display State Matrix

The following table details the standard bit assignments within the 32-bit .EventState structure:

Bit PositionHex ValueMessage Class / Event CategoryVisual Indicator in Group DisplayFlashing BehaviorBit 016#00000001Alarm High (Active)Red Symbol (A)Steady Red (if acknowledged)Bit 116#00000002Alarm Low (Active)Red Symbol (A)Steady Red (if acknowledged)Bit 216#00000004Warning High (Active)Yellow Symbol (W)Steady Yellow (if acknowledged)Bit 316#00000008Warning Low (Active)Yellow Symbol (W)Steady Yellow (if acknowledged)Bit 416#00000010Tolerance EventWhite / Blue Symbol (T)Steady SymbolBit 1616#00010000Unacknowledged Alarm HighRed Symbol (A)Flashing Red (Alarm Unack)Bit 1716#00020000Unacknowledged Alarm LowRed Symbol (A)Flashing Red (Alarm Unack)Bit 1816#00040000Unacknowledged WarningYellow Symbol (W)Flashing Yellow (Warning Unack)Bit 2416#01000000Message Locked / SuppressedLock / Padlock SymbolSuppresses acoustic horn.

Step-by-Step Procedure to Trace and Verify Group Display Annunciation

Method: Configuring and Auditing Group Displays

  1. Open the OS project in WinCC Explorer.
  2. Ensure Alarm Logging is active in Computer Properties > Startup.
  3. Double-click OS Project Editor; execute with default layout to initialize system message classes.
  4. Open a process picture in Graphic Designer.
  5. Insert a Group Display object from the Smart Objects palette.
  6. Open object properties; locate property Group Value.
  7. Connect Group Value directly to the technological block's .EventState tag (e.g. TIC_101/PIDConL.EventState).
  8. In CFC Test Mode, simulate an alarm condition by forcing process input PV_In above the high limit (PV_AH_Lim).
  9. Monitor .EventState in a WinCC Tag Status view. Confirm that Bits 0 and 16 assert (16#00010001).
  10. Verify that the Group Display flashes red. Acknowledge the alarm via faceplate; confirm that Bit 16 resets (16#00000001) and the display transitions to steady red.

Verification

To verify .EventState and Group Display integrity:

  1. Normal Operational State: Ensure process inputs are within limits. Confirm that .EventState = 0 and the Group Display displays no alarm symbols.
  2. Warning Annunciation: Force a high warning. Confirm that .EventState asserts bit 2 and bit 18 (16#00040004), displaying a flashing yellow warning.
  3. Hierarchy Propagation: Navigate to the top-level Plant Overview screen. Confirm that the area button corresponding to the faulted picture indicates active warning.

Limitations and Operational Precautions

  • Do Not Overwrite .EventState in Scripts: Never write values to .EventState from user C-scripts or VB scripts; the tag is managed exclusively by the AS-OS communication driver.
  • Custom Message Classes: If custom message classes are configured in Alarm Logging, ensure their bit assignments do not overlap standard PCS 7 message bit definitions.
  • Alarm Suppression: When using the APL Alarm Suppression feature (MsgLock = 1), .EventState asserts the locked bit to suppress operator alarms during planned equipment maintenance.

Engineer FAQ

Why does .EventState = 0 show an empty group display instead of 'Normal' text?

By design, WinCC Group Displays remain dark/blank when no alarms exist, minimizing screen clutter for operators.

Can Group Displays be linked to non-APL boolean tags?

Standard Group Displays require a 32-bit DWORD tag structured to match message classes; linking raw booleans requires custom converter scripts.

Does .EventState consume WinCC archive tags?

No. .EventState is an internal process tag used exclusively for live graphic animation; it is not logged in historical Tag Logging.

Technical References

Related Articles

Related Tags

  • https://industrialautomation.net/search?query=simatic-pcs7
  • https://industrialautomation.net/search?query=wincc
  • https://industrialautomation.net/search?query=alarms
  • https://industrialautomation.net/search?query=diagnostics
6 respuestas