Eliminating Duplicate Alarms in WinCC V6.2 Redundant Servers

Problem Summary

In a Siemens PCS7 OS Server pair running WinCC V6.2 over ProfiNet with CP1613 communication processors, operators report that the same alarm message appears twice in the WinCC Alarm Control view. The two entries are byte-for-byte identical: same message number (MsgNr), same text, same state (came-in / went-out), same priority, same acknowledgement status, and—most diagnostically—the same timestamp down to the millisecond.

The behaviour is reproducible across reboots, across both OS Servers, and across WinCC Client stations. It is therefore not a transient race condition or display flicker; it is a structural duplication introduced by one of eight recurring configuration defects in the redundancy pair, the Alarm Control view, or a downstream consumer such as Microsoft SQL Server reporting.

This article isolates the eight most common root causes seen on WinCC V6.2 SP2 through SP4 PCS7 OS server pairs, and provides the configuration corrections and verification steps used in the field.

WinCC V6.2 Redundancy Architecture

WinCC V6.2 redundancy requires the WinCC/Redundancy option (MLFB 6AV6371-1CF06-2AX0) on top of WinCC/Server (6AV6371-1CA06-2AX0). The two servers exchange a continuous life beat over TCP and synchronize Tag Logging, Alarm Logging, and User Archive contents when a server comes back online after a failover.

The defining characteristic of PCS7 OS server redundancy is that both OS Servers receive every alarm message from the Automation Stations (AS). This is by design: each OS has its own S7 connection set to the AS using CP1613 (MLFB 6GK1161-3AA00 / -3AA01), and the AS multicasts message events to both subscribers. The redundancy mechanism exists for archive survivability and failover—not for input deduplication.

Two consequences follow that directly drive the duplicate-alarm symptom:

1. Each OS Server's local alarm archive contains a complete, independent copy of every alarm event ever received from the AS.
2. A WinCC Client that connects to both OS Servers receives both copies unless it is explicitly configured to query only one preferred server at a time.

If both copies appear in a single Alarm Control view with identical timestamps, the cause is almost always at the client/view layer (WinCC Client package or WebNavigator client), at a misrouted S7 connection, or at a downstream consumer (SQL Server, Reporting Services, custom C/VB action). Cross-check the redundancy settings against the procedure in Siemens Support Entry 24023824 — PCS7 OS Server redundancy configuration.

Diagnostic Decision Tree

The flowchart below covers the eight failure modes that produce byte-identical duplicates. Work them in order from most likely (AlarmControl misconfiguration) to least likely (message-class UUID collision).

Root Cause Matrix

Cause 1: AlarmControl Queries Both OS Servers

This is the most common cause and the one most often mistaken for a server-side bug. When the Alarm Control is embedded in a WinCC Client picture and the project was not packaged with proper Preferred Server selection, the runtime control issues OLE-DB queries against both partner server archives simultaneously.

Configuration path: in WinCC Explorer of the WinCC Client project, open the Alarm Control configuration dialog and inspect:

• Selection - Server prefix: must reference exactly one server prefix (e.g. ::SERVER1: or ::SERVER2:) - not both, not blank.
• Properties - Server assignment: Preferred Server field must be set; Preferred Server for Server-Client Operation must be true.
• Connection - Server name: must match the WinCC Server project name, not the local machine name when the picture runs on a WinCC Client.

If the picture was created on the OS Server and copied to the Client without resetting the Server Name binding, the client runtime queries both archives in parallel and renders each entry once per server.

Cause 2: Tag-Triggered Message on Both Servers

If the same bit-triggered or value-triggered message is configured in Alarm Logging on both OS Servers, and both servers poll the same tag through independent S7 connections, the condition fires simultaneously on both servers at the same millisecond. The duplicate is therefore two genuine event instances, but the source of the duplication is configuration, not network or hardware.

Verify by opening Alarm Logging - Message Configuration on OS1 and OS2. The recommended pattern in PCS7:

• Define the message on the ES (Engineering Station) and use the OS server assignment to route the message to a single OS.
• OR: define the message only on one OS Server (the "alarm owner") and rely on archive synchronization to mirror the entry to the partner.

If both OS Servers list the same message number for the same trigger tag, delete the message from the secondary OS and rely on redundancy sync.

Cause 3: Alarm Logging Redundancy Disabled

WinCC/Redundancy synchronises Alarm Logging entries automatically when this option is enabled. If disabled, the partner server has no record of events that occurred during a failover window. More relevant to this article, the AlarmControl may compensate by querying both archives to display a "complete" picture - and this double-querying produces the duplicate.

Enable on each server: Alarm Logging - Properties - Redundancy tab - Synchronize Alarm Logging = checked. Both server prefixes must be configured under Computer - Properties - Redundancy.

Cause 4: Time Synchronisation Misrouted

Identical millisecond timestamps on two independent servers only occur when both servers are receiving their time from the same master (typically the AS using S7 time, or an external NTP/SICLOCK source). When the setup is correct, you should see entries arrive within 1-3 seconds of each other on the two OS Servers - not at the same millisecond.

Identical timestamps therefore strongly suggest a single message instance was inserted twice into one archive (Cause 1, 2, 5, 6, 7, or 8) rather than two independent events on different servers.

Verify Time Synchronization: Time Synchronization Editor - Standby / Master / Slave. The Slave should point to the partner server, not to the AS, to avoid both OS Servers being slaves of the same source.

Cause 5: S7 Connection Duplicated in Tag Management

When the project was duplicated from OS1 to OS2 using the OS Project Duplicator, the Tag Management structure was copied. If the engineer forgot to disable the AS connection on OS2, both OS Servers have an active S7 connection to the same AS. Each connection triggers message events on its host, so the same alarm fires twice - once per connection.

Inspect Tag Management - SIMATIC S7 PROTOCOL SUITE - TCP/IP - [connection] on both OS Servers. Each AS should appear as a connection on exactly one OS Server. Use connection naming conventions (e.g. AS1_OS1 and AS1_OS2) to make ownership obvious at a glance.

Cause 6: SQL Server Double-Write

If the user is forwarding WinCC alarm events to a Microsoft SQL Server table for reporting - the most commonly referenced consumer in the support case history - the duplicate can be produced entirely on the SQL side. Typical causes:

• The SQL INSERT is performed in both an Alarm Logging Action and a separate Global Script C-action triggered on the same alarm event.
• The Report Designer runs the same alarm report on both OS Servers and both write to the same SQL table.
• Database mirroring or replication is misconfigured, causing the secondary to receive inserts twice.

Verify with SQL Server Management Studio:

SELECT MsgNr, COUNT(*) AS Duplicates
FROM dbo.AlarmLog
GROUP BY MsgNr
HAVING COUNT(*) > 1
ORDER BY Duplicates DESC;

If duplicates only appear in SQL Server (and not in WinCC Alarm Control), the WinCC side is innocent.

Cause 7: User Archive / DBM Double-Write

Custom VB or C actions in Global Script that write to User Archive or to an external ODBC database are common culprits. If the action is bound to an alarm event and executes on both OS Servers, the database receives two inserts.

Wrap the action with @CurrentServerName or check HMIRuntime.BaseTagName to ensure the action runs only on the preferred server:

if (HMIRuntime.Tags("@CurrentServer").Read() == "OS1") {
    // insert into user archive or ODBC
}

Cause 8: Project Duplicator Message-Class Collision

The PCS7 "OS Project Duplicator" copies the entire project from OS1 to OS2 but does not regenerate message class UUIDs. If both projects are run side-by-side in a WinCC Client package, the client can mistakenly query the same message class on both archives and produce duplicates in the combined view.

Resolution: after duplication, open Alarm Logging - Message Classes on the duplicate server, regenerate the class IDs (right-click - Regenerate), then re-deploy.

Fixing the AlarmControl Server Selection

The single most impactful change for the duplicate-alarm symptom is to make the AlarmControl aware of redundancy. Open the AlarmControl properties in Graphics Designer on the WinCC Client:

1. Selection tab: in Server, enter the computer name of the preferred server (e.g. \\OS1). Use @CurrentServer for dynamic resolution.
2. Source tab: set Source of messages to "Server" (not "Local").
3. Properties tab: enable Use server-side filtering and set Message filter to Server = 'OS1'.
4. Configuration tab: set Update cycle to 1000 ms or higher (the default 500 ms can amplify display duplicates).
5. Compile and re-deploy the picture to all WinCC Clients.

Enabling Alarm Logging Redundancy

On each OS Server:

1. Open WinCC Explorer - Computer - Properties - Redundancy.
2. Enter the partner server name, the partner server prefix (must differ from the local prefix), and the redundancy TCP port (default 5050).
3. Open Alarm Logging - Properties - Redundancy tab: enable Synchronize Alarm Logging.
4. Open Tag Logging - Properties - Redundancy tab: enable Synchronize Tag Logging if process values are involved.
5. Restart both OS Servers in the order specified by the redundancy configuration (master first).

CP1613 and ProfiNet Considerations

The CP1613 (SIMATIC NET PCI card, MLFB 6GK1161-3AA00) is the standard ProfiNet/Industrial Ethernet interface for WinCC Server projects. For redundancy:

• Each OS Server has its own CP1613 installed and addressed with a unique MAC/IP.
• The CP1613 firmware version must match on both stations - mismatched firmware (e.g. one at V2.4 and one at V3.0) can cause intermittent message loss and trigger redundant retries that appear as duplicates.
• Verify with the SIMATIC NET Configuration Console: Modules - CP1613 - Diagnostics - Firmware Version.
• PG/OP communication must be enabled on every CP1613 used for WinCC traffic. Without it, S7 message frames from the AS do not reach WinCC.

Reference the SIMATIC NET CP1613 manual (A5E00252888-02, edition 04/2007) for full installation and firmware details.

Time Synchronisation Best Practice

The recommended topology for a PCS7 OS server pair:

• One external time master (SICLOCK or NTP stratum-1).
• One OS Server set as Time Master, the other as Time Slave pointing to the partner.
• The AS slaves off the OS Master.
• Client stations slave off the active OS.

This daisy-chain avoids the "both OS slaves of same source" scenario that produces identical timestamps.

Field Diagnostic Procedure

Follow this sequence in the field. Document each step in the change log.

1. Reproduce: trigger a known alarm and observe the Alarm Control. Record the MsgNr, timestamp, server prefix column, and the database name shown in the AlarmControl status bar.
2. Identify scope: does the duplicate appear (a) only in WinCC Alarm Control, (b) only in SQL Server, or (c) in both?
3. Server prefix check: right-click each duplicate row - Properties. If the server prefix differs, Cause 1 is active.
4. Alarm Logging properties: on each OS, open Alarm Logging - Properties - Redundancy tab. Confirm the checkbox is set on both.
5. Tag Management scan: export the connection list from both servers and diff. Any AS appearing on both servers indicates Cause 5.
6. SQL Server scan: run the duplicate MsgNr query above on the SQL target.
7. Global Script audit: open Global Script - Actions on both OS and search for HMIRuntime.Trace or INSERT INTO referencing the alarm table.
8. Time Sync audit: confirm only one OS is Time Master, the other is Slave pointing to the partner.
9. CP1613 firmware parity: check both firmware versions, update the older to match the newer.
10. Message class UUIDs: export message classes from both servers and compare UUIDs.

Verification Checklist

Edge Cases and Field-Proven Caveats

• WinCC V6.2 SP3 hotfix 6+: a regression in the AlarmControl server-prefix resolver was corrected. If you cannot upgrade, manually bind the Server field on every Alarm Control instance.
• WebNavigator client: the WebNavigator published view always queries both OS servers unless the WinCC User Administrator explicitly assigns the user to one server only. This is by design in WebNavigator V6.2 but produces duplicates. Use the WinCC User Administrator - User Groups - Server Assignment to restrict.
• OS Server cloning with PCS7 V7+: V7 introduced a different project duplicator flow that regenerates server prefixes automatically. If you can upgrade the OS pair, many of these duplicates vanish.
• OPC-DA bridge into WinCC: any third-party OPC server that fans out alarms to both WinCC servers will duplicate the event. Configure the OPC bridge to publish to one OS only.
• CPU 417-4H redundant AS: the AS itself can send the same alarm twice if both H-CPUs are active and the message was not acknowledged before the master switched. Confirm AS redundancy state in the CFC diagnostics picture.
• Message frame ordering: S7 alarms use sequence numbers. If sequence numbers reset during a redundancy switch, you may see ghost acknowledgements that look like duplicates in AlarmControl. Inspect SIMATIC S7 PROTOCOL SUITE - Diagnostics - Sequence errors.

SQL Server Audit Script

Run this on the SQL Server hosting the WinCC alarm archive to detect duplicates and pinpoint the writer:

-- Detect duplicates by message number and timestamp
SELECT
    MsgNr,
    DateTime,
    COUNT(*) AS DupCount,
    MIN(ServerName) AS FirstServer,
    MAX(ServerName) AS LastServer
FROM dbo.ArchivedAlarms
WHERE DateTime > DATEADD(day, -7, GETDATE())
GROUP BY MsgNr, DateTime
HAVING COUNT(*) > 1
ORDER BY DupCount DESC;

-- Identify the writer application
SELECT DISTINCT
    ServerName,
    HostName,
    ProgramName
FROM dbo.ArchivedAlarms
WHERE MsgNr IN (
    SELECT MsgNr FROM dbo.ArchivedAlarms
    GROUP BY MsgNr, DateTime HAVING COUNT(*) > 1
);

WinCC V6.2 SP Compatibility Notes

FAQ