PCS7 Safety Matrix Viewer Blank Matrix: Troubleshooting & Fix

Problem Summary

The SIMATIC PCS 7 Safety Matrix Viewer on the Operator Station (OS) opens either an outdated version of the cause-and-effect matrix or a completely blank viewer — with no cause rows and no effect columns — immediately after a successful CFC chart download, AS-OS engineering transfer, and OS recompile. The Safety Matrix Engineering Tool on the Engineering Station (ES) continues to monitor the new matrix correctly, but the OS Runtime Viewer does not reflect the edited logic. The symptom is specific to the interaction between the Safety Matrix Engineering/Viewer components and the WinCC graphics runtime on the OS, and it is most often observed on PCS 7 V8.0 SP2 through V8.2 with Safety Matrix V6.2 SP1 and WinCC V7.2.

Reported Workflow

1. Edit the Safety Matrix in the Safety Matrix Engineering Tool (V6.2 SP1) to add new interlocks.
2. Transfer the matrix to the project — no compile errors, no warnings.
3. Compile the CFC chart that owns the matrix block — no errors, no warnings.
4. Download the CFC chart to the AS — no errors, no warnings.
5. Confirm the new matrix is visible in the Safety Matrix Engineering Tool monitor mode.
6. Compile the OS with "Changes Only" — no errors, no warnings.
7. Start OS Runtime — clicking the Safety Matrix block icon opens the OLD matrix (cached/pre-edit version).
8. Compile the Entire OS (full rebuild) — no errors, no warnings.
9. Restart OS Runtime — clicking the icon now opens a BLANK Safety Matrix Viewer with no cause/effect rows.

The compile chain reports no errors and no warnings at any stage. The Engineering Tool shows the correct matrix. Only the OS-side Viewer is degraded. This decoupling between the ES monitor and the OS Viewer is the diagnostic signature of the failure.

Affected Software Environment

The behavior has been reproduced and analyzed against the following Siemens product stack. Other patch combinations may exhibit the same symptom if the Safety Matrix-to-OS data hand-off is not fully refreshed. Always verify the patch stack on every node before troubleshooting.

Safety Matrix Data Flow Architecture

The OS Viewer does not query the AS in real time for the matrix structure; it consumes a cause/effect XML that is generated by the Safety Matrix Engineering Tool and committed to the OS server project directory during OS compile. The Viewer then renders the XML through a set of WinCC faceplates that are bound to specific block icon families. Understanding this hand-off is the key to diagnosing both the "stale" and "blank" symptoms.

XML and Faceplate Hand-off Sequence

The matrix data path on the OS side comprises three artifacts:

• Matrix XML file — generated by the Safety Matrix AS-OS Engineering package during OS compile and stored under the project directory. Default location: <Project>\Library\SafetyMatrix\ or <Project>\GraCS\ depending on the matrix library generation. The XML carries cause rows, effect columns, interlock logic, and the matrix instance ID.
• WinCC faceplate — the graphical template (typically prefixed @PG_MA_AL on PCS 7 V8.x; older libraries use the matrix-specific @SM_* prefix) that the Viewer instantiates to render each matrix block.
• Graphic object instance — the placement of the faceplate on a WinCC picture. The instance carries a unique block-instance ID that binds the faceplate to a specific matrix XML.

If any of the three artifacts is out of sync with the others, the Viewer degrades. The matrix XML being newer than the faceplate produces a "stale" symptom. The matrix XML being newer than the graphic object instance produces the "blank" symptom.

Symptom Variants

Two distinct symptoms have been reported from the same underlying failure, with a third variant specific to redundant OS pairs. Identifying which variant is present determines the diagnostic path.

Root Cause Analysis

Five distinct — and sometimes overlapping — root causes have been confirmed for this failure. Treat them as a checklist; resolve in the order listed because the cheaper checks (faceplate regeneration, OS Project Editor) clear most field cases without an OS full compile.

Root Cause 1 — Redundant OS Server Prioritization

In a redundant OS server pair (OS Server A / OS Server B), the Safety Matrix Viewer on the OS client reads matrix data from the OS server that holds the master role for the project — but it does not honour the OS client's preferred-server assignment the way standard WinCC tag access does. If only one server (typically Server B used for the test) was updated with the new matrix XML, the Viewer may still pull the cached XML from Server A because the redundancy role for the matrix data path was not switched. The result is a Viewer that "works on the test server but not in production" — a classic dead giveaway that the redundant-pair synchronization is incomplete.

Diagnostic: On the ES, open WinCC Explorer on each redundant OS server and compare the timestamp of the matrix XML under the project directory. The server with the older timestamp is the one the Viewer is reading. Cross-check with the WinCC Redundancy diagnostic log to confirm the master/standby role assignment at the time of the failed open.

Root Cause 2 — Faceplate Generation Not Refreshed

The Safety Matrix Viewer uses WinCC faceplates that are tied to the specific matrix block icon family installed on the ES. When a new matrix version is introduced — or when the Safety Matrix block icon library is updated — Chapter 2.4 of the Safety Matrix manual requires that the OS faceplates be regenerated. The OS Project Editor performs this regeneration as part of its run, but only if it is explicitly invoked after the matrix transfer. A "Changes Only" OS compile does not necessarily invoke the faceplate regeneration pass.

Diagnostic: Open WinCC Explorer on the OS server, navigate to the project's graphics library, and inspect the modification timestamp of the @PG_MA_AL faceplates (or the equivalent matrix faceplate prefix shipped with the matrix library). If the timestamp predates the matrix transfer, the faceplates are stale. Compare the same timestamp on OS Server A and OS Server B in a redundant pair.

Root Cause 3 — OS Project Editor Not Run

The OS Project Editor (Tools → OS Project Editor in SIMATIC Manager) updates the graphic objects, server assignments, area hierarchy, and the Safety Matrix faceplate links that the Viewer depends on. Skipping it — or letting it run only in "preview" mode — leaves the Viewer pointing at a block instance whose supporting graphic objects no longer exist. Symptom B (blank viewer) is the most common outcome. The OS Project Editor is also responsible for wiring the AS-OS connection tags that the Viewer uses to read live state from the AS, so skipping it can produce both blank-viewer and no-live-update symptoms simultaneously.

Root Cause 4 — Compile Mode (Changes Only vs. Entire OS)

"Compile OS (Changes Only)" performs an incremental compile and may not regenerate dependent objects if the matrix change does not register as a structural change to the S7 program (for example, when the change is purely logical within the cause/effect rules). "Compile Entire OS" forces a full rebuild but, if the previous compile state was inconsistent, can paradoxically produce the blank viewer if the matrix XML is regenerated before the faceplates are re-linked. The correct sequence is: transfer matrix → OS Project Editor → Entire OS compile. Out-of-sequence compiles are a frequent cause of the variant B symptom.

Root Cause 5 — AS-OS Engineering Linkage Stale

The Safety Matrix AS-OS Engineering package bridges the CFC chart (where the matrix block instance lives) and the OS picture (where the icon is placed). If the chart is downloaded to the AS but the AS-OS link is not refreshed, the Viewer can locate the icon but cannot resolve the cause/effect instance ID, producing an empty grid. This is most common after importing a chart from another project, after manually renaming a matrix block, or after a STEP 7 project reorganization that moves the chart to a different hierarchy level.

Diagnostic Procedure

Execute the following checks in order. Stop at the first check that resolves the symptom and proceed to Verification. Document each check's outcome; if the issue requires escalation to Siemens Support, the diagnostic log is invaluable.

1. Confirm engineering monitor. Open the Safety Matrix Engineering Tool on the ES, connect to the AS in monitor mode, and verify the new matrix is visible and active. If the ES monitor also shows stale data, the issue is upstream and the OS Viewer cannot be fixed until the ES side is correct.
2. Inspect the OS matrix XML timestamp. On each OS server in the redundant pair, navigate to the project directory (default: <Project>\Library\SafetyMatrix\ or <Project>\GraCS\) and identify the matrix XML file. Compare the file modification time against the time of the most recent matrix transfer. A timestamp older than the transfer indicates the XML was not refreshed.
3. Inspect faceplate timestamps. In WinCC Explorer on the OS server, navigate to Graphics → Library and inspect the matrix faceplate set. If timestamps predate the matrix transfer, the faceplates are stale. Pay particular attention to the @PG_MA_AL family.
4. Compare OS server A vs. B. If the project is on a redundant OS pair, run steps 2 and 3 on both servers. A timestamp mismatch between the two confirms redundant-update drift. A faceplate mismatch between the two confirms the OS Project Editor did not run on both servers.
5. Check OS Project Editor run log. The OS Project Editor produces a log file under the project directory. Verify the most recent run touched the matrix area and the graphic objects. If the log is missing or stops before the matrix section, the Editor did not complete.
6. Check the OS client preferred-server assignment. On the OS client, in WinCC Explorer, open the server list and confirm the preferred server for the matrix data path. Remember that the Viewer may not honour this list (see Root Cause 1) — the diagnostic is informational, not corrective.
7. Verify the CFC chart download on the AS. In STEP 7 on the ES, open the CFC chart that owns the matrix block and confirm the block icon name and instance ID match what the OS picture expects. A mismatch indicates the AS-OS Engineering linkage is stale.
8. Inspect the WinCC alarm log. On the OS server, open the WinCC Alarm Control and search for messages containing "Matrix", "Faceplate", or "@PG_MA_AL". Messages such as "Matrix data not found" or "Faceplate type not loaded" point directly at the missing or stale artifact.

Corrective Procedure

The corrective procedure is divided into five parts. Execute Part A first; only advance to the next part if the Viewer still misbehaves. Parts A through C resolve the majority of field cases; Part D is reserved for stubborn cases; Part E is specific to redundant pairs.

Part A — Re-transfer Matrix with Position Update

1. On the ES, open the Safety Matrix Engineering Tool.
2. Select the matrix and choose Transfer → To Project.
3. Enable the option With position / alarm block update if available in your Safety Matrix version. This forces the transfer to overwrite the position table and the alarm block assignments on the OS, which the Viewer's "stale" symptom depends on.
4. Select Update all rather than Update changes only.
5. Confirm the transfer completes without errors or warnings.
6. Recompile the CFC chart that owns the matrix block and download to the AS.

Part B — OS Project Editor

1. In SIMATIC Manager on the ES, select the OS and choose Tools → OS Project Editor.
2. Run the OS Project Editor with all default sections enabled. Pay particular attention to the Graphics and Runtime sections, which rebuild the matrix faceplate links and re-bind the matrix block instance IDs.
3. Confirm the OS Project Editor log reports successful regeneration of the matrix graphic objects. The log file is written to the project directory under OSPE.log or equivalent.
4. If the project has multiple OS stations (server pair + clients), run the OS Project Editor for each OS station individually — running it once for the master does not propagate to clients.

Part C — Regenerate and Save Faceplates Manually

If the Viewer still shows a blank matrix after Parts A and B, the faceplate instances in the OS picture must be refreshed directly. This is the single most effective field fix for variant B (blank viewer) and is documented in the Siemens Safety Matrix support knowledge base.

1. On the OS server, open WinCC Explorer.
2. Navigate to the project's picture tree and open every picture that contains a Safety Matrix block icon. Typical pictures include the area overview, the unit overview, and the unit-level OS pictures.
3. For each picture, open every faceplate instance whose name begins with @PG_MA_AL (or the matrix faceplate prefix shipped with your Safety Matrix version) by double-clicking it.
4. Close each faceplate with OK (not Cancel) to force a save. This re-instantiates the faceplate and re-binds it to the current matrix XML on disk.
5. Repeat the picture-by-picture open-and-save pass on every OS server in a redundant pair.
6. For OS clients, the regenerated faceplate set is loaded at Runtime startup, so a single OS Runtime restart is sufficient.

Part D — Full OS Compile with Memory Reset

Use this step only if Parts A through C do not clear the symptom. A memory-reset compile destroys the OS Runtime state and forces a clean rebuild — schedule it for a process-safe maintenance window with the plant in a stable, supervised state. Note that a memory-reset compile resets all Runtime persistent settings and trends, so back up the project before proceeding.

1. Stop OS Runtime on all OS servers and OS clients.
2. In WinCC Explorer on the OS server, choose Tools → Compile → Entire OS.
3. In the compile options, enable Memory reset (full rebuild).
4. Start the compile and monitor the output log for matrix-related warnings. A clean compile produces zero matrix-related entries.
5. After the compile completes, restart OS Runtime on the standby server first, then the master server, then the OS clients — this sequence ensures the redundancy state initializes correctly.

Part E — Redundant Pair Synchronization

If the project runs on a redundant OS pair and only one server was updated during the test:

1. Execute Parts A through D on Server A first (the master), then on Server B (the standby).
2. After both servers compile, force a redundancy sync by toggling the master role from A to B and back. Verify that the Viewer's matrix display is identical on a test client pointed at each server during the role change.
3. If the Viewer still diverges between the two servers, open a Siemens Support Request with the WinCC redundancy diagnostic log (Redundancy.log) and the OS Project Editor log attached.
4. For PCS 7 V8.2 and later, verify that the WinCC Redundancy package is at the latest hotfix level — mixed patch levels between the redundant pair can reintroduce the divergence after a restart.

Verification Checklist

After each corrective part, verify the result with the following sequence. Do not consider the issue resolved until every item passes. Capture the verification results in the change record.

Predictive Indicators and Early Warning

Before the Viewer degrades fully, several observable conditions can act as leading indicators. Building a daily check that monitors these reduces mean-time-to-repair.

• XML timestamp drift between redundant servers: if a daily file-watch job reports that the matrix XML on Server B is more than one transfer cycle older than Server A, the redundant update is drifting. Run Part E proactively.
• OS Project Editor log gap: if the last OSPE.log entry is older than the last matrix transfer, the Editor was not run. Run Part B before the next OS Runtime restart.
• Faceplate checksum mismatch across OS clients: deploying a script that computes a hash of the @PG_MA_AL faceplate set on every OS client at Runtime startup and reports divergence to a central log surfaces client-side drift before operators do.
• WinCC alarm pattern: a rising count of "Matrix data not found" or "Faceplate type not loaded" messages over a 24-hour window is a strong leading indicator that the Viewer is about to degrade.

Predictive Indicators and Early Warning

For larger PCS 7 installations with dozens of OS stations, automating the diagnostic procedure via a scheduled task on the OS server is the most reliable way to catch the failure before operators report it. A minimal automation approach uses a PowerShell or CMD script that runs hourly and checks:

1. The modification timestamp of the matrix XML on each OS server.
2. The presence of the expected faceplate set in the project library.
3. The freshness of the OSPE.log relative to the last matrix transfer timestamp (recorded in a sidecar text file written by the matrix transfer script).

If any check fails, the script writes a WinCC system message or sends an email to the control room. This automation adds minutes of effort to a project change but saves hours of unplanned troubleshooting per year.

Comparison: PCS 7 V8.x vs. PCS 7 V9.x Behavior

PCS 7 V9.0 and later ship with the Safety Matrix in the new style integrated into the TIA-based engineering. The failure mode described in this article is specific to the classic PCS 7 stack (STEP 7 V5.x, WinCC V7.x, Safety Matrix V6.x). For migration context:

If you are planning a migration from PCS 7 V8.x to V9.x, the corrective procedures in this article are obsolete after migration because the matrix data path changes fundamentally. Document the migration as a project milestone and re-validate the Viewer behavior immediately after the cutover.

Edge Cases and Field-Proven Caveats

• Multi-project OS stations: when a single OS station hosts multiple PCS 7 projects (common in large refineries), the matrix transfer from one project can invalidate faceplates of another project if the picture names collide. Open and save all @PG_MA_AL faceplates across all projects on the OS station.
• Custom user-defined faceplates: if the project replaces the default matrix faceplate with a custom one, the manual regeneration in Part C must be repeated for the custom faceplate. The default regeneration logic in the OS Project Editor does not touch user-defined faceplates.
• OS Client with local project cache: PCS 7 OS clients can optionally run with a local project copy for faster startup. After a matrix change, the local cache must be invalidated. Use the OS Client Setup wizard to refresh the local project.
• Antivirus interference: some antivirus products quarantine files matching the matrix XML pattern during OS compile, leading to a "matrix missing" symptom that mimics a Viewer fault. Add the matrix XML directory to the antivirus exclusion list.
• Time skew between ES and OS: if the ES clock and OS clock are more than a few seconds apart, the matrix XML timestamp comparison in the diagnostic procedure can be misleading. Synchronize both nodes to the same NTP source before troubleshooting.

Preventive Best Practices

• Always run the OS Project Editor after every Safety Matrix transfer, even when the matrix change is small. The Editor's incremental mode is fast and prevents the Viewer's stale-XML class of fault.
• Always update the master OS server first in a redundant pair, then the standby. Never test matrix changes on the standby alone — the Viewer prioritizes the master and the standby update will be ignored.
• Lock the Safety Matrix version across ES and both OS servers. Mixed patches (for example, ES on V6.2 SP1 and OS on V6.2 base) are a documented cause of XML format drift.
• Schedule a quarterly faceplate refresh: open every matrix faceplate on each OS server, close with OK, and recompile. This prevents drift between the faceplate generation on disk and the matrix XML in memory.
• Use the matrix transfer log as a controlled document: capture the transfer timestamp, the matrix XML checksum, and the operator initials every time a matrix change ships to production.
• Test matrix changes on the engineering OS first before pushing to production OS servers. The engineering OS is single-server and avoids the redundant-pair prioritization footgun entirely.
• Maintain a watchdog script on each OS server that reports daily on the matrix XML timestamp, the faceplate set checksum, and the OSPE.log freshness. Detect drift before operators report it.
• Document the Viewer verification step in the project's Management of Change (MOC) procedure. Operators must confirm the Viewer shows the new matrix before the change is signed off.

Frequently Asked Questions