Troubleshooting Missing Alarm Display on WinCC OS Clients in Multi-Server PCS 7 Architectures

In multi-server SIMATIC PCS 7 architectures (e.g., PCS 7 v6.1, v7.x, v8.x, v9.x with distributed DCS and ESD/safety servers), alarms failing to display on WinCC OS Clients while showing correctly on local OS Servers is caused by missing or unassigned Server Data packages (*.pck), WinCC User Administrator area authorization restrictions, or Simatic Shell network resolution failures. To resolve this, generate and export Server Data packages from all OS Servers, load and assign the packages in the OS Client project, verify in WinCC User Administrator that the operator account has authorization for all Plant Hierarchy areas, and confirm Terminal Bus hostname resolution across all subnets.

Multi-Server Alarm Routing Architecture in PCS 7

In distributed SIMATIC PCS 7 architectures, OS Clients do not communicate directly with automation controllers (AS) to acquire process alarms. Instead, an OS Client acts as a multi-client node that subscribes to multiple autonomous OS Servers (such as DCS Server 1, DCS Server 2, and ESD / SIS Safety Servers).

Each OS Server executes its local CCAlgRtServer.exe process (WinCC Alarm Logging Server). When an AS controller issues an ALARM_8P message, the responsible OS Server logs the event into its local Microsoft SQL Server database. The OS Client connects to the OS Server over the Terminal Bus and requests alarm records via Remote Procedure Calls (RPC) and Microsoft Message Queuing (MSMQ).

To display alarms from multiple servers in a single unified WinCC AlarmControl on an OS Client:
1. Each OS Server must compile its database and generate a Server Data Package (a .pck file containing tag prefixes, server names, and message class mappings).
2. The OS Client must import and load each server's .pck file.
3. The WinCC AlarmControl must be configured with 'Use of global message classes' enabled.
4. The logged-in Windows/WinCC user must possess valid area access authorizations for the areas mapped to each server.

Primary Causes of Client Alarm Suppression

When an OS Client displays alarms from only one server (e.g., DCS 1) while completely ignoring alarms from DCS 2 or the ESD server, the issue stems from one of four technical layers:

Unassigned or Stale Server Data Packages: The OS Client project on the Engineering Station has not loaded the updated .pck file for DCS 2 or ESD. If the client project only has DCS 1's package loaded, Alarm Logging ignores all external server data.
WinCC User Administrator Area Authorization: In PCS 7, every alarm is automatically associated with a Plant Hierarchy area (e.g., Area_DCS1, Area_ESD). If the user account logged into the OS Client lacks authorization for the ESD area, WinCC silently filters out those alarms from the AlarmControl banner and alarm list.
Simatic Shell Terminal Bus Interconnect Disruption: If Terminal Bus network settings, network adapter prioritization, or Windows hosts file mappings prevent the OS Client from reaching the secondary servers via NetBIOS or RPC, the client establishes an alarm session only with the primary reachable server.
AlarmControl Message Filter Constraints: If the WinCC AlarmControl in @AlarmNew.pdl or @AlarmActive.pdl has a hardcoded SQL filter or server selection parameter, messages originating from non-selected server prefixes are excluded.

Diagnostic and Configuration Workflow

Execute the following systematic procedure to diagnose and restore missing client alarms:

Step 1: Re-generate and Download Server Data Packages

On the Engineering Station (ES), open the SIMATIC Manager Multiproject.
Right-click the OS Server project for DCS 1 and select Compile. Ensure the OS compile completes cleanly.
In SIMATIC Manager, right-click the OS Server project for DCS 2 and select Generate Server Data. Repeat for the ESD OS Server.
Right-click the OS Client project in SIMATIC Manager and select Assign OS Server....
In the assignment dialog, ensure checkmarks are active for DCS 1, DCS 2, and ESD Server packages.
Right-click the OS Client and select PLC > Download. Download the client project to the target physical OS Client station.

Step 2: Verify Package Status in WinCC Explorer on the Client

On the OS Client, open WinCC Explorer.
Expand the navigation tree and select Server Data.
In the right pane, verify that packages for DCS 1, DCS 2, and ESD appear with status Loaded and correct server names.
If a package is missing, right-click Server Data, select Load..., navigate to the shared project directory, and import the missing .pck file.

Step 3: Check WinCC User Administrator Permissions

In WinCC Explorer on the OS Server (or via Central User Administrator / SIMATIC Logon), open User Administrator.
Select the user group assigned to operators (e.g., Operators).
Examine the authorization matrix under Area Authorizations.
Confirm that the operator group has authorization (Function 1: 'Enable for Area') checked for ALL plant areas, including DCS 2 and ESD units. If an area authorization is unchecked, WinCC suppresses that area's alarms.

Step 4: Validate Simatic Shell and Network Resolution

On the OS Client, open Windows Explorer, right-click Simatic Shell, and select Settings....
Verify that the correct physical network card bound to the Terminal Bus is selected.
Confirm that Encrypted Communication settings match across all servers and clients.
Open a Windows Command Prompt and ping each OS Server by hostname (e.g., ping SERVER_ESD). If ping fails or returns an IP from the Plant Bus rather than the Terminal Bus, update the C:\Windows\System32\drivers\etc\hosts file.

Multi-Server Alarm Parameter Matrix

The following matrix details the critical parameters governing multi-server alarm propagation to WinCC OS Clients:

Configuration ParameterLocationRequired SettingDiagnostic Impact When MisconfiguredServer Data (*.pck)OS Client > WinCC Explorer > Server DataAll server packages loaded and updatedClient receives zero alarms or tags from unassigned serverStandard ServerOS Client > Server Data > Standard ServerAlarms: No standard server (or specific designated server)Alarm submission or message generation routed incorrectlyArea AuthorizationWinCC User Administrator'Enable for Area' active for all Plant AreasAlarms from unauthorized areas are hidden without error messagesSimatic Shell AdapterWindows Explorer > Simatic Shell > SettingsTerminal Bus NIC selected on all nodesRPC communication fails; client displays disconnected statusGlobal Message ClassesWinCC AlarmControl > Message Blocks'Use of global message classes' = YesInconsistent color schemes and missing message class groupshosts File MappingC:\Windows\System32\drivers\etc\hostsHostname mapped to Terminal Bus IP addressClient attempts RPC over incorrect network interface

Verification

To verify that all OS Servers propagate alarms to the OS Client:
1. Log into the OS Client using a standard operator account.
2. Open the WinCC Alarm banner or alarm list (@AlarmActive.pdl).
3. Generate a test alarm or warning on DCS 1, DCS 2, and the ESD system (e.g., force a simulated channel fault or toggle a test interlock).
4. Verify that alarms from all three sources appear simultaneously in the client alarm list with correct server prefixes, time stamps, and event texts.
5. In the alarm list, check the Server Name column to ensure entries from DCS1_OS, DCS2_OS, and ESD_OS are visible.
6. Open the WinCC system diagnostic window (apdiag.exe) and check the AlarmLogging output channel for any connection timeout warnings.

Limitations and Operational Precautions

Observe the following engineering constraints in multi-server WinCC environments:
- Redundant OS Server Pairs: When redundant OS servers are employed, verify that both the master and standby packages are generated and that the OS Client has redundant server pairs configured under Server Data.
- Do Not Assign Standard Server for Alarms: On multi-client systems with multiple independent servers, do NOT designate a 'Standard Server' for Alarms unless all alarms are intentionally aggregated into a single centralized alarm logging server. Leaving it unassigned allows the client to receive alarms from all loaded packages.
- Time Synchronization Requirement: All OS Servers and OS Clients must be synchronized to a common central time master (e.g., SICLOCK or NTP). Time drift between DCS and ESD servers causes out-of-order alarm sorting and false alarm acknowledgments.

Engineer FAQ

Why do alarms show on the local OS Server but not on the OS Client?

The most common reason is that the OS Client has not loaded the updated Server Data package (*.pck) from that OS Server, or the operator logged into the client lacks Area Authorization in WinCC User Administrator for the plant section where the alarm originated.

Do I need to compile the OS Client every time I modify alarms on an OS Server?

No. When you modify alarms on an OS Server, you only compile that specific OS Server and generate its Server Data. Then, in SIMATIC Manager, you update the server data on the OS Client and download the changes to the client.

How does Simatic Shell affect multi-server alarm distribution?

Simatic Shell coordinates name resolution and secure RPC endpoints across the Terminal Bus. If Simatic Shell is bound to the wrong network adapter, the client cannot establish the RPC connection needed to subscribe to the remote server's Alarm Logging service.