Resolving PCS7 WinCC Quality Code 0x4C and Phantom HH Alarms on Custom P_AI Blocks

This field reference documents a recurring PCS 7 / WinCC Runtime fault pattern where a custom P_AI function block reports an apparently normal process variable on the AS, yet the Operator Station (OS) raises a phantom High-High (HH) alarm, paints the block icon magenta (bad quality), and shows several internal alarm outputs (MHH, HH, LL, MLL, SB_LL) as 0 even though the AS logic returns 1. The WinCC tag tooltip reports a quality code of 0x4C (76 decimal) instead of the expected 0x80 (128 decimal, good). The pattern has been reproduced on PI-1001A/AI and PI-5803/AI in a PCS 7 V9.x system that uses an APL-derived, site-customised P_AI faceplate and block icon. Recovery is possible without deleting the FBs in production, but only when the underlying cause is correctly identified.

This article maps the symptom matrix to the OPC UA quality code dictionary that WinCC uses, isolates the root cause to WinCC-side tag database state rather than PLC logic, and presents the engineer-to-enginener procedure used to clear the fault on a live system. Examples target the SIMATIC PCS 7 portfolio; behaviour is consistent from V8.2 through V10.0 and the WinCC Runtime Professional that ships with it.

1. Problem Statement

On a fully commissioned PCS 7 process cell, two analog input tags - PI-1001A/AI and PI-5803/AI - began to display the following anomalous behaviour on the OS server graphics:

• An HH alarm appears in the Incoming Alarm List although the process value is sitting at roughly 10% of the configured range.
• The block icon background is rendered magenta, which the APL faceplate template uses to indicate a bad PV quality (typically a sensor short circuit).
• The block icon does not show the B text marker and does not show the HH suffix that the template normally displays next to the value.
• In the group icon the AL indicator is red (active), but the HIGH HIGH text box itself is grey, which is the rendered state when the alarm is acknowledged but not currently active.
• The B indicator in the group icon is magenta (active), but the FAULT text box is grey and the SC text next to PV is not present.
• HH and SC alarms no longer appear in the faceplate alarm window, even though they were visible in the days before. The reason is that Alarm Logging is configured with a 1-week retention and the older events have been moved to the CAS (Central Archive Server) and are no longer queryable from the live list.

Reading the live values from the AS side via STEP 7 / CFC online shows all alarm outputs (HH, LL, HF_HL, HF_LL, CH_QBAD, MO_EN, MO_TMR, MO_SET, MO_RST, SBC, SB_LL, MHH, MLL) at 1 - i.e. healthy. The process value is correct, and the channel driver on the ET 200SP / ET 200M AI module shows status 0x80 (good).

2. Symptom Matrix

The combination of block icon magenta + FAULT text grey + alarm unacknowledgeable is the fingerprint of a WinCC tag-database inconsistency, not a true field fault.

3. WinCC Quality Code Reference

WinCC tag quality codes are aligned with the OPC UA status code convention. The codes observed in this fault pattern are listed below.

For this article, the two codes that matter are 0x80 (good, what we want) and 0x4C (uncertain - substitute value, what we see). The 0x4C value is the OPC UA status Uncertain_SubstituteValue combined with the limit bit pattern; in WinCC it is most often a side-effect of either a tag that is configured but not referenced anywhere in graphics, scripts, alarms, or archives, or of a WinCC-side internal copy that has not been refreshed after a delta OS compile.

4. Root Cause Analysis

Three hypotheses were evaluated against the evidence in the source field case. Only the third matches every observation.

4.1 Hypothesis A - PLC logic fault

If the P_AI function block on the AS were the cause, the online view in CFC would show alarm outputs at 0 and the PV would be outside the configured range. The observed evidence is the opposite: PV is normal, alarm outputs are 1, channel diagnostics show 0x80. This hypothesis is rejected.

4.2 Hypothesis B - Safety / HH configuration on PCS

The process cell uses a PCS (non-safety) controller, and HH alarms are not normally configured on the PCS for this class of measurement. The HH limit file was checked on the ES and no HH threshold exists for either tag. The HH message visible in the Incoming Alarm List was not generated by the AS alarm logic. This hypothesis is rejected.

4.3 Hypothesis C - WinCC-side tag database inconsistency on a delta-loaded picture

This is the surviving hypothesis. The OS was delta-compiled (Changes Only) after a CFC modification. The customised P_AI block icon and faceplate were not re-rendered with a full compile. The WinCC internal image of the flag tags (HH, LL, MHH, MLL, SB_LL) lost their tag-binding to the picture object. The PLC keeps reporting 1, but the picture's internal cache reports 0 with quality 0x4C (uncertain - substitute value). A subsequent online read from Tag Management on the server shows the same mismatch.

The decisive evidence: when the P_AI function block was deleted from the CFC and the OS recompiled with Changes Only on a replicated engineering laptop, the problem disappeared. That test result points firmly at WinCC-side state corruption on a single function-block instance, not at runtime corruption of the PLC program or the PCS 7 master database.

5. Why Deleting the FB Works (And Why You Cannot Do It on a Live System)

When a customised faceplate is bound to a CFC instance, WinCC stores the binding in an internal picture-local list keyed by the CFC instance name. A Changes-Only delta compile rebuilds the picture only for the changed instances; the picture-local binding for the changed instance is regenerated, but on certain combinations of customised faceplate, modified script interface, and modified alarm class the regeneration drops the runtime binding for one or more flag tags. The flag tag then becomes "configured but unreferenced from any active picture" and WinCC reports it as 0x4C.

Deleting the FB and re-compiling Forces-Only re-establishes the picture-local binding from scratch. The reason this is not a viable production remedy is that any untouched FB still bound to the same customised faceplate retains its corrupt binding, and forcing a full OS compile on a live plant takes the system offline. The remaining sections describe how to clear the fault without that step.

6. Prerequisites for Recovery

Before any of the procedures below are executed, confirm the following:

1. The ES, OS server, and OS clients all run the same PCS 7 version (V8.2 / V9.0 / V9.1 / V10.0 with the matching hotfix level). Mixed versions cause exactly the kind of quality-code 0x4C symptom described here.
2. The redundant OS server pair is healthy, with both servers in standby-master state and no messages in the Redundancy window.
3. The AS is in Run with no system faults on the CPU diagnostic buffer.
4. There is a current backup of the PCS 7 project (.p7* zip) and a recent image of the OS server volumes.
5. The WinCC Alarm Logging retention is known. In the source case, retention was 1 week and old HH / SC events had been moved to CAS, which is why they no longer appear in the faceplate alarm window.

7. Step-by-Step Recovery Without Deleting FBs

7.1 Step 1 - Confirm the PLC side is clean

On the ES, open the CFC online view for the affected AS, navigate to the P_AI instance, and capture a screenshot of every input and output. The PV, PV_FAC, PV_OUT, and alarm outputs HH, H, L, LL, MHH, MLL, HF_HL, HF_LL, CH_QBAD, SBC, SB_LL, MO_EN, MO_TMR, MO_SET, MO_RST should all be at their healthy values. If any of these are at 0 on the AS, the problem is in the CFC, not in WinCC, and you must fix the CFC first.

7.2 Step 2 - Read the OS-side tag quality

On the OS server, open WinCC Explorer, expand Tag Management, right-click each of the flag tags listed above, and read the value and quality code from the tooltip. Record the values in a worksheet. The expected quality code is 0x80; the observed value is 0x4C for the flag tags that are out of sync. This is the live evidence that the problem is WinCC-side.

7.3 Step 3 - Re-synchronise the picture binding

This is the corrective step that does not require deleting any CFC instance.

1. Open the affected process picture on the ES in Graphics Designer.
2. Select the customised P_AI block icon instance.
3. Open the Properties > Events dialog and confirm the configured event names match the customised faceplate script interface. A mismatch in the interface is a common cause of dropped bindings after a delta compile.
4. Open Compile OS > Changes Only, and tick Update picture objects. Run the compile.
5. Download the delta to the standby OS server and let redundancy synchronise.
6. Wait for the redundancy sync to complete, then fail over the master. Verify the picture now shows white background and no HH message.

If the binding is still mismatched, force a recompile of the single picture file by right-clicking it in WinCC Explorer > Graphics and selecting Recompile. The single-picture recompile is much faster than a full OS compile and is safe on a running plant because it does not restart the OS server process.

7.4 Step 4 - Clear the latched message in Alarm Logging

The HH message visible in the Incoming Alarm List was generated before the binding was repaired and is still latched internally. Clearing it requires the Siemens support procedure that was attempted in the source case, plus a small refinement that fixes the root cause: the WinCC internal message state bit is reset by triggering a state change on the bound tag, not by writing to a custom binary tag.

1. On the ES, open Alarm Logging and locate the HH message by message number. Note the message number, the message class, and the bound tag.
2. In the CFC, force a brief 0 -> 1 -> 0 transition on the bound alarm-output tag (for example, momentarily force the HH threshold one count higher and back). This causes the AS to send a fresh, good-quality message that the OS can latch and acknowledge normally.
3. On the OS server, refresh the Incoming Alarm List. The phantom HH row should now be replaceable by a fresh, acknowledgeable message. Acknowledge it.
4. If a fresh message is not generated (the bound tag is stuck at 0 in the OS internal state), then the message-class binding itself is the broken element. Proceed to Step 5.

7.5 Step 5 - Reset the WinCC message class binding

This is the procedure recommended by Siemens support for the rare cases where a message class loses its tag binding after a delta compile:

1. Write down the message number of the unacknowledgeable HH message.
2. On the ES, open the project, and create a binary tag in Internal Tags named for example ResetMsg_PI1001A.
3. Open Alarm Logging, search for the message number, and reassign its Trigger Tag to the new internal binary tag.
4. Implement an E/A field in a process picture, link the field to the new internal tag, and save.
5. Download the server (delta).
6. On the OS server, set the new internal tag to 1 and then back to 0. This forces a new timestamp on the message and re-marks it as acknowledgeable.

8. PCS 7 Alarm Logging and CAS Archive Settings

The original fault report noted that the HH and SC alarms were visible in the faceplate alarm window in the days prior to the failure and were no longer visible at the time of investigation. The reason is the 1-week retention configured in Alarm Logging. After one week, events are moved to the CAS (Central Archive Server). The faceplate alarm window is bound to the live Alarm Logging database, not to CAS, and therefore the older events are not displayed.

To inspect the archived events, open the Tag Logging / Alarm Logging archive viewer, connect to the CAS, and query the message number and time range. If the events are present in CAS but absent from the live faceplate, this confirms the time-bound nature of the symptom and is not by itself evidence of a fault.

Retention that is too short causes the engineer to lose the very events needed to diagnose an intermittent fault. Retention that is too long fills the CAS volume. The values above are a reasonable starting point for a small to mid-size cell.

9. Cross-Reference Verification (Tag in Use)

WinCC treats a tag as in use only if it is referenced from at least one of: a graphics object, a script, an alarm, an archive, or a global action. A tag that is configured in Tag Management but is not referenced anywhere will be reported as quality 0x4C by the runtime, because the runtime is not subscribed to it from the AS.

To confirm whether the affected flag tags are referenced, run Cross Reference on the ES against the WinCC project and search for each tag name. The output will list the picture files, scripts, and alarms in which the tag appears. If the flag tag is only listed in Tag Management and nowhere else, then the 0x4C code is "by design" and the tag should either be referenced or removed.

The macro from the field report captured this diagnosis exactly: the tag was in use only in a C / VBScript that the runtime did not flag as a subscriber, so the WinCC internal image of the tag drifted to 0x4C whenever the subscribed picture was not currently open. When the picture displaying the block icon is opened, the runtime resubscribes and the value briefly becomes 0x80. This is consistent with the observation in the source case that the H and L tags changed state when the picture was opened.

10. Diagnosing Bad Quality from Customised Faceplates

The block icon's magenta background is a feature of the customised faceplate that is bound to a quality-code field on the bound tag. When the field is 0x4C, the faceplate paints magenta. The standard APL P_AI faceplate uses the same convention. The differentiation between "bad quality - sensor failure" (which would also show the B text marker) and "uncertain - substitute value" (which does not) is signalled by the lower nibble of the quality code.

The fact that the block icon shows magenta without the B marker is a reliable on-screen diagnostic: the faceplate is reporting a quality code with an uncertain severity bit, not a bad severity bit. This narrows the search to the 0x40-0x7F range and confirms the WinCC-side state hypothesis.

11. Prevention and Hardening

Three engineering controls reduce the likelihood of recurrence.

11.1 Always run a full OS compile after customising a faceplate

A Changes-Only compile is not sufficient to refresh the picture-local binding list for a customised faceplate when the script interface or alarm class has been modified. After any modification to a customised faceplate, run a full OS compile, not a delta compile, then download the full OS image. The full compile forces every picture to re-bind against the new faceplate interface.

11.2 Use the standard APL P_AI faceplate where possible

Customised faceplates and block icons are a common source of binding drift. If the project can be aligned to the standard APL P_AI faceplate, the change reduces the surface area of script-interface mismatches. For projects that require a customised faceplate, freeze the script interface and alarm class on a single PCS 7 version and avoid modifying them on a running plant.

11.3 Avoid improper shutdown of the OS server

A power-cut to the OS server, a forced kill of the WinCC Explorer process, or an out-of-cycle restart of the redundancy service can leave the alarm-logging database and the picture-binding database in inconsistent states. Use the OS server Shut down menu option (not a hard power-off), and protect the OS volume with a UPS sized for at least 10 minutes of runtime to allow a graceful shutdown.

11.4 Periodic Cross-Reference audit

Run a full Cross-Reference of the WinCC project once per quarter and verify that every tag with quality 0x4C is either genuinely unreferenced (and therefore a candidate for removal) or is referenced by a picture, script, alarm, or archive. Quality 0x4C is the most common early indicator of a binding drift before it becomes a hard fault.

12. Verification Checklist

13. Frequently Asked Questions

14. Standards and References

• OPC UA Part 4 - Services, status code 0x4C00 (Uncertain_SubstituteValue) and 0x0000 - 0x8000 quality mask.
• SIMATIC PCS 7 Process Control System - Operator Station manual, chapter "Alarm Logging and CAS".
• SIMATIC PCS 7 - APL Style Guide, sections on P_AI faceplate and quality code mapping.
• WinCC Unified documentation - Alarm control overview (WinCC Unified RT).

The WinCC Unified alarm control reference above documents the modern successor to the classic WinCC Alarm Control used in PCS 7 V9.x and earlier. Engineers maintaining legacy PCS 7 cells can use it as a reference for the alarm-control object model when planning an upgrade to PCS 7 V10 / WinCC Unified RT.