WinCC 7.0 Group Display Troubleshooting: Status Tag Bit Mapping

Problem Description

In a WinCC V7.0 runtime project, a group display element wired to a 32-bit StatusTag and a 32-bit MessageTag (split into two 16-bit tags) fails to settle into the steady, acknowledged state after the operator presses the Acknowledge button in the alarm banner. The high-priority (AH) and low-priority (AL) buttons continue to flash, and a second group display embedded in a higher-level overview picture never reports the alarm at all. Alarm Logging posts the system message "1011001 The group display hierarchy is not up-to-date" in the diagnostic window even after the Dynamic Wizard Connect group display with picture has been run, the picture hierarchy has been refreshed, and CCCSigRTServer and CSIG.exe have been added to the computer startup list in the WinCC Explorer.

The configuration that reproduces the failure is a common WinCC V6-to-V7 migration layout:

• MessageTag = two concatenated unsigned 16-bit internal tags ALM_Hi (high word) and ALM_Lo (low word), forming a 32-bit message number. MessageBit = 1 (bit 0 begins the message-number evaluation).
• StatusTag = single unsigned 32-bit tag. StatusBit = 15 maps the AL button, StatusBit = 14 maps the AH button.
• Masking value of the group display object = 3089 (WinCC default).
• Picture tree: process picture Pic.PDL hosts a group display instance, and an overview picture hosts a second group display that the Dynamic Wizard Connect group display with picture has wired to the same picture tree.

Observed symptoms at runtime:

1. Writing decimal 2 (binary 0000 0000 0000 0010) to ALM_Lo raises the AH button (bit 14 set) and the LED blinks indefinitely; no steady state appears on acknowledge.
2. Writing decimal 2 to ALM_Hi raises the AL button (bit 15 set) and the LED blinks indefinitely.
3. A second message number written to the message tag has no visible effect: the display continues to flash the original AH/AL state.
4. Clicking Acknowledge in the alarm banner clears the alarm line but the group display LED keeps flashing.
5. The overview group display shows nothing; the internally generated tag @Pic_Pic_PDL reads 0x0000FFFF (high word 0x0000, low word 0xFFFF) regardless of activity in Pic.PDL.
6. Alarm Logging repeatedly posts "1011001 The group display hierarchy is not up-to-date".

WinCC 7.0 Group Display Architecture

A WinCC group display is a small graphics object from the Standard or Siemens HMI Symbol Library palette that aggregates the active alarms of a process picture into a stack of single-bit indicators. Internally, the group display does not poll Alarm Logging directly. It evaluates a single status word whose bits encode CAME, GONE, ACKNOWLEDGED, and the priority flags AH / AL for the highest-priority message in the picture. The picture's group value is published to the rest of the runtime through an internal tag whose name follows the pattern @<PictureName>_<PDL_FileName>, and the overview picture subscribes to that internal tag through the picture hierarchy.

Three elements must agree for a group display to render the correct visual state:

1. Message number propagation — the message tag (or two-tag pair) must reflect the message number currently being signalled by Alarm Logging for the picture.
2. Status word evaluation — the status tag must be updated by Alarm Logging with the runtime status of that message, and the group display's mask must include the bits that determine the on / off / blink state.
3. Picture hierarchy resolution — the overview picture's group display must be able to resolve the internal @Pic… tag of the source picture. This requires the picture hierarchy to be regenerated, the runtime signal service to be loaded, and the signal server process to be running.

For a comprehensive description of the data flow consult the Siemens Industry Online Support portal, search entry WinCC V7 Group Display, and the local WinCC Information System under Options > Alarm Logging > Group display.

Status Word Bit Map Reference

The StatusTag of a group display follows the standard WinCC alarm status word layout. The 32-bit status word is bit-indexed from 0 (least significant). The bit positions relevant to a group display are listed below. The values shown reflect the convention used by the Alarm Logging runtime in WinCC V7.0 / V7.4; verify against the local WinCC Information System for any service pack update.

Root Cause 1: Message Tag and Status Tag Evaluation Order

The first anomaly — "the group display only flashes the original AH/AL state when a second message number is written" — is a direct consequence of how Alarm Logging drives the StatusTag. The status word is updated only for the message number currently registered in Alarm Logging. If the message tag is written to a new value, but the source that would generate the corresponding alarm event is not triggered, Alarm Logging leaves the old status word in place and the group display continues to show the previous state.

In the reported configuration, the engineer wrote ALM_Lo = 2 to trigger message number 2, then changed the tag to a different value. Without an actual alarm event coming from the PLC (or a forced one in the alarm simulator), Alarm Logging does not refresh the status word, so the AH/AL bits that were set by the first trigger remain set in the StatusTag until the matching GONE event arrives.

This is expected behaviour, not a configuration error. It is included here because it is the most common source of confusion during WinCC V7 commissioning: the group display is a consumer of the Alarm Logging engine, and forcing the MessageTag alone is not sufficient to drive the StatusTag transitions. To test the picture correctly, use the WinCC alarm simulator (WinCC > Tools > Alarm Simulator) or trigger the alarm from the connected PLC.

Root Cause 2: Default Mask Value 3089 and the Acknowledged Bit

The default mask value of the group display object is 3089 (decimal) = 0x0C11 = binary 0000 1100 0001 0001. The mask is bitwise ANDed with the status word: bits where the mask is 1 are evaluated, bits where the mask is 0 are ignored. The default mask therefore evaluates bits 0, 4, 10 and 11 only.

Bit 2 (ACKNOWLEDGED) is not included in the default mask. As a result, when the operator presses Acknowledge and Alarm Logging sets bit 2 in the StatusTag, the group display does not register the transition. The CAME bit (bit 0) remains set, the AH or AL bit (bit 14 / 15) remains set, and the group display continues to display the alarm as if it were still unacknowledged. Because the WinCC group display's blink logic is driven by the combination of "alarm active" and "not acknowledged", the LED keeps blinking even after the alarm line goes steady.

Bit-by-bit breakdown of the default mask 3089:

The mask in WinCC V7 controls the logical state evaluation of the group display (acknowledge, gone, error), while the StatusBit selection controls the visual assignment of the LEDs. This separation is the source of the confusion: changing the mask does not change which button lights up, it changes the criteria under which the button stops blinking.

To include the ACKNOWLEDGED bit (bit 2) in the evaluation, set the mask to:

mask_new = 3089 OR (1 << 2) = 3089 + 4 = 3093 (decimal) = 0x0C15

For a more permissive evaluation that also captures the GONE bit (bit 1):

mask_new = 3089 OR (1 << 1) OR (1 << 2) = 3089 + 2 + 4 = 3095 (decimal) = 0x0C17

For a fully transparent evaluation (use during commissioning only — it exposes every status transition to the group display, including the reserved bits):

mask_new = 0xFFFF = 65535 (decimal)

Root Cause 3: Internal @Pic Tag in Overview Pictures

The group display in the overview picture does not subscribe to the same StatusTag as the group display in Pic.PDL. It subscribes to a self-generated internal tag whose name is constructed by the picture hierarchy service. The naming convention in WinCC V7 is:

@<PictureName>_<PDL_FileName_Without_Extension>

For a picture named Pic stored in the file Pic.PDL, the internal tag is @Pic_Pic. For a process picture opened inside a picture window with the picture name Sub, the internal tag is @Sub_<PDL> where <PDL> is the file name of the picture currently loaded in the window. These tags are 32-bit and follow the same bit layout as the regular StatusTag, but they are updated by the picture hierarchy service, not by Alarm Logging directly.

The pattern reported in the field — @Pic_Pic = 0x0000FFFF regardless of activity in Pic.PDL — is the classic "hierarchy not yet initialised" signature. The low word (0xFFFF) corresponds to the error / invalid pattern emitted by the picture hierarchy service before it has completed its first handshake with the source picture. The high word (0x0000) is the default for the message number area, indicating that no message number has been registered from the source picture.

Three things must happen for the @Pic… tag to be populated with the live status of Pic.PDL:

1. The picture hierarchy in WinCC Explorer must be regenerated and deployed to runtime (the Dynamic Wizard Connect group display with picture performs this step).
2. The runtime signal service (CSIG.exe) must be running on the WinCC server and on every WinCC client that hosts the overview picture.
3. The signal runtime server (CCCSigRTServer.exe) must be running and connected to the signal service. The signal runtime server is the process that receives the picture-level group value from Alarm Logging and publishes it to the @Pic… tags.

Until all three are true, the overview group display reads the default error pattern and remains dark. The 0x0000FFFF pattern is the symptom; the missing initialisation of the picture hierarchy and the signal server chain is the cause.

Root Cause 4: Runtime Components CCCSigRTServer and CSIG.exe

Two runtime processes participate in the propagation of the group value from the source picture to the overview picture. Both must be loaded for the @Pic… tag to update correctly.

CSIG.exe — WinCC Signal Service

The signal service is a low-level Windows process that brokers signal / event traffic between the Alarm Logging runtime, the picture hierarchy service, and the signal runtime server. It is started by the WinCC runtime manager as part of the computer startup list. In WinCC Explorer, add CSIG.exe under Computer > Properties > Startup. The service creates a local IPC channel (named pipe) on the WinCC server and accepts connections from local and remote WinCC clients.

CCCSigRTServer.exe — Signal Runtime Server

The signal runtime server is the process that actually subscribes to the Alarm Logging engine and translates the picture-level group values into @Pic… tag updates. It must be running on every WinCC station that hosts a group display element. In a distributed WinCC V7 project (server + clients), the signal runtime server runs on the server; on a single-station project, it runs on the same machine as the runtime. Add it under Computer > Properties > Startup.

For a single-station WinCC V7 project, the minimum required startup processes for a working group display hierarchy are:

1. CCCSigRTServer.exe — signal runtime server
2. CSIG.exe — signal service
3. CCAlarmMonitor.exe — alarm logging runtime
4. CCEs.exe — WinCC runtime manager

For a multi-station project, the signal service runs on the server, and the signal runtime server runs on both the server and every client that hosts a group display. Confirm the process list with the Windows Task Manager on the affected station. If CCCSigRTServer.exe is missing from the process list, the @Pic… tag will not receive updates and the overview group display will read 0x0000FFFF.

Root Cause 5: Error 1011001 Picture Hierarchy Warning

System message "1011001 The group display hierarchy is not up-to-date" is generated by the picture hierarchy service when it detects that the deployed picture tree in runtime does not match the picture tree in the WinCC Configuration Studio. The message is informational — it does not stop the runtime — but it indicates that the @Pic… tags are not yet bound to the source picture objects and the overview group display will not receive updates until the binding is established.

Three conditions trigger the warning:

1. The picture hierarchy was edited in the Graphics Designer after the last Connect group display with picture run.
2. A new picture was added to the project tree (a process picture, a faceplate, or a picture window) and the overview group display was not reconnected.
3. The Dynamic Wizard Connect group display with picture has been run, but the WinCC project has not been recompiled and redeployed to runtime.

The warning clears automatically when the next full project compile completes and the picture hierarchy service re-initialises. In some WinCC V7 service packs, the warning persists for a few minutes after redeployment while the signal service rebuilds its internal tag map; this is normal and does not indicate a configuration error.

Verify the picture hierarchy integrity:

1. In WinCC Explorer, expand Graphics Designer > [project tree] > Picture hierarchy.
2. Confirm that Pic.PDL appears under the correct parent node and that the overview picture lists Pic.PDL as a child reference.
3. Right-click the picture hierarchy and select Check consistency. The tool reports any orphan or missing picture references.
4. If the tool reports a missing reference, re-run the Dynamic Wizard Connect group display with picture from the overview picture.

Graphics Designer Configuration Walkthrough

The group display object exposes the configuration fields in the Graphics Designer property dialog. Open the object with a double-click and navigate to the Miscellaneous tab. The fields relevant to this troubleshooting guide are:

If the MessageTag is split into two 16-bit tags, the high-word tag ALM_Hi must be configured in a second group display property (or as an additional MessageTag in the message class configuration) so that the full 32-bit message number can be reconstructed. The naming convention follows the High-Word Tag field in the message class editor under Alarm Logging > Message Classes > [class] > Properties > Message Tag.

Mask Value Calculator

The mask value is a 16-bit integer applied bitwise AND to the lower 16 bits of the StatusTag. Use the formula below to compute a mask for any combination of status bits:

mask = SUM ( 1 << n ) for every status bit n to be evaluated

Common mask values used in WinCC V7 projects:

Step-by-Step Resolution Procedure

Apply the following steps in the order shown. The procedure is written for a single-station WinCC V7.0 project. For a multi-station project, repeat the runtime steps on every station that hosts a group display element.

1. Verify the StatusTag layout in Alarm Logging. Open the WinCC Explorer, expand Alarm Logging, and select the message class used by the group display. Confirm that the StatusTag is configured as a 32-bit unsigned tag and that the StatusBit field is set to 1 (the bit evaluation starts at bit 0 of the 32-bit word). If the status tag is split across two 16-bit tags, confirm the high-word / low-word assignment matches the documentation in the WinCC Information System under Alarm Logging > Configuration > Status tag.
2. Set the group display mask value. Open the group display object in the Graphics Designer, navigate to Properties > Miscellaneous > Masking value, and replace the default 3089 with the appropriate value for your project:

   3089 + 4 = 3093  (CAME + STATUS + ERROR + ACKNOWLEDGED)
   3089 + 2 + 4 = 3095  (CAME + GONE + STATUS + ERROR + ACKNOWLEDGED)
   65535  (full evaluation — commissioning only)

   Save the picture and close the Graphics Designer.
3. Verify the MessageTag concatenation. If the message number requires more than 16 bits (uncommon, but supported in WinCC V7), confirm that the high-word tag ALM_Hi is the high word of the 32-bit value, and the low-word tag ALM_Lo is the low word. A common commissioning error is to swap the two tags, which causes the high-numbered messages to read as the low-numbered ones and vice versa. A simple cross-check: write ALM_Hi = 0x0001 and ALM_Lo = 0x0000 and verify that the message number 65536 is signalled.
4. Regenerate the picture hierarchy. In WinCC Explorer, open the overview picture in the Graphics Designer, select the group display, and re-run the Dynamic Wizard Connect group display with picture. The wizard re-establishes the binding between the overview group display and the source picture's @Pic… tag.
5. Recompile and redeploy the project. In WinCC Explorer, right-click the project name and select Rebuild > All. After the build completes, restart the WinCC runtime. The picture hierarchy service and the signal service re-initialise during the startup phase; system message 1011001 should clear within 60–120 seconds of a clean restart.
6. Add the runtime components to the computer startup list. In WinCC Explorer, right-click the computer name and select Properties > Startup. Confirm that the following processes are listed in the order shown:
   1. CCCSigRTServer.exe
   2. CSIG.exe
   3. CCAlarmMonitor.exe
   4. CCEs.exe
   If any of these are missing, add them using the Add… button. The order matters: the signal service must be loaded before the signal runtime server attempts to subscribe to it.
7. Verify the runtime processes are running. After restarting the WinCC runtime, open the Windows Task Manager on the affected station and confirm that CCCSigRTServer.exe and CSIG.exe are present in the process list. If either is missing, check the WinCC diagnostic log under Computer > Diagnostics > ApDiag for the corresponding startup error.
8. Test the group display. Trigger an alarm from the connected PLC (or from the WinCC alarm simulator). Confirm that the group display in Pic.PDL shows the correct AH/AL LED, that the LED transitions from blinking to steady on acknowledgement, and that the overview group display updates to the same state within one screen refresh cycle. If the overview group display does not update, refer to the troubleshooting matrix in the next section.

Verification and Commissioning Test

The commissioning test exercises every transition of the group display state machine. Run the test once with the default mask value 3089 (to reproduce the original failure) and once with the corrected mask value (to confirm the resolution). The test must be executed in a non-production environment; the alarm simulator or a test PLC is sufficient.

1. Initial state. Confirm that all group display LEDs are dark, the StatusTag reads 0x0000 0000, and the @Pic… tag reads 0x0000 0000 in the WinCC tag simulator.
2. Trigger alarm. Force the PLC tag that drives message number 2. Confirm that:
   • The alarm line in the alarm banner shows the new message with the correct priority (AH or AL).
   • The StatusTag transitions to 0x0000 C002 (CAME + AH + status; bit positions per the layout in the Status Word Bit Map Reference section).
   • The group display in Pic.PDL lights the AH button and the LED blinks.
   • The @Pic_Pic tag transitions from 0x0000 0000 to 0x0000 C002 within one screen refresh cycle (typically 250 ms in WinCC V7).
   • The overview group display lights the AH button and the LED blinks.
3. Acknowledge. Click the alarm line in the alarm banner and press Acknowledge. Confirm that:
   • The alarm line transitions to the acknowledged state (visual change: bold becomes non-bold, the acknowledge icon appears).
   • The StatusTag transitions to 0x0000 4002 (CAME + AH + ACKNOWLEDGED; bit 2 set).
   • The group display in Pic.PDL stops blinking; the AH LED is now steady on.
   • The overview group display stops blinking; the AH LED is now steady on.
   If the LEDs continue to blink, the mask value still excludes the ACKNOWLEDGED bit. Return to step 2 of the resolution procedure and add bit 2 to the mask.
4. Return to normal. Clear the PLC tag that drives the alarm. Confirm that:
   • The alarm line transitions to the "gone" state (visual change: status icon changes, the alarm row leaves the active list).
   • The StatusTag transitions to 0x0000 4006 (GONE + ACKNOWLEDGED + AH; bits 1, 2, 14 set).
   • The group display in Pic.PDL darkens the AH button.
   • The overview group display darkens the AH button.
5. Trigger a second alarm. Force the PLC tag that drives message number 3. Confirm that:
   • The group display transitions to the new message (the higher-priority message wins if both are active).
   • The StatusTag updates to reflect the new message number and the new status bits.

Edge Cases and Multi-Station Considerations

Redundant WinCC servers. In a WinCC redundancy pair, the signal service runs on both the master and the standby. After a failover, the @Pic… tags on the client are updated by the new master within one polling cycle (typically 1–2 seconds). During failover, expect the overview group display to read 0xFFFF FFFF for up to 5 seconds; this is normal and does not require intervention.

Picture windows inside picture windows. If Pic.PDL is loaded inside a picture window inside the overview, the internal tag name uses the full hierarchy: @<OuterPicture>_<InnerPicture>_<PDL>. The Dynamic Wizard Connect group display with picture resolves the full chain automatically — do not edit the binding manually.

Faceplates loaded as picture windows. Faceplates in WinCC V7 follow the same rule: the internal tag uses the faceplate instance name plus the base picture name. If the faceplate is renamed, the @Pic… tag is renamed accordingly and the overview group display must be reconnected.

WebNavigator clients. A WebNavigator client does not run the signal service locally; it subscribes to the signal service on the WinCC server. The @Pic… tag is created on the server and mirrored to the client through the WebNavigator plug-in. If the overview group display is shown inside a WebNavigator-published picture, the CCCSigRTServer.exe must be running on the WinCC server, not on the WebNavigator client.

WinCC V6 to V7 migration. Projects migrated from WinCC V6 to V7 may carry the V6 default mask value 0x0C01 (3073). The V7 default 3089 adds the STATUS bit (bit 4) but not the ACKNOWLEDGED bit. Reset the mask to 3095 in every migrated project to match the V7 expected behaviour.

Troubleshooting Matrix

The matrix below maps the observed symptom to the most likely cause and the corresponding resolution step. The matrix is sorted by symptom, not by cause; use the symptom column to find the matching row.

FAQ