Architectural Design and Alarm Synchronization for Merged Flat and Client-Server PCS 7 Systems

In SIMATIC PCS 7, merging a centralized Client-Server architecture with decentralized Single-Station OS nodes allows plant-wide supervisory control from a central OS Server while providing autonomous local area operation during central server failures. However, because independent Single Stations are not WinCC Redundancy partners to the central server, native WinCC Redundancy cannot synchronize historical alarms or process values. To achieve unified alarm and data synchronization across the entire plant, deploy SIMATIC Process Historian (PH) as a central long-term archive to which both the central OS Server and local Single Stations forward their historical records.

Executive Summary

Large industrial facilities often seek to balance centralized plant management with local operational resilience. In a conventional PCS 7 architecture, plants select either a centralized Client-Server hierarchy (with redundant OS Servers and multi-client stations) or a flat architecture (with independent Single-Station OS nodes mapped directly to automation controllers). Increasingly, plant specifications demand a merged hybrid architecture: a central supervisory OS Server monitors the entire site, while dedicated Single-Station OS nodes govern individual process units autonomously, maintaining local operation if the central server fails.

While this hybrid topology provides exceptional operational survivability, it introduces a major technical challenge: historical alarm and process data synchronization. Engineers frequently assume that WinCC Redundancy can sync historical alarms between the central server and the local single stations once the central server recovers. However, WinCC Redundancy operates strictly between paired redundant servers, not across independent project nodes. This guide analyzes the operational mechanics of merged PCS 7 architectures, outlines controller connection rules, and details how SIMATIC Process Historian resolves historical alarm synchronization.

Architecture and Fundamental Mechanics

The merged architecture requires precise segregation between runtime supervisory control and historical data archiving:

Runtime Communication Layer (Plant Bus & Controllers):
- In the merged architecture, S7-400/410 controllers reside on the Industrial Ethernet Plant Bus.
- The central OS Server establishes named S7 connections to ALL controllers across the entire plant.
- Each local Single-Station OS establishes named S7 connections ONLY to the controllers governing its specific plant unit (e.g., Unit 1 AS).
- Both the central server and the local single stations independently query process data and receive cyclic ALARM_8P event messages directly from the controllers.
The WinCC Redundancy Limitation:
- WinCC Redundancy synchronization (CCRedSync.exe) is designed exclusively for a dual-redundant server pair sharing a single common project database.
- Independent Single-Station OS nodes host distinct project databases with unique local computer names and tag management tables. They cannot be configured as redundant partners to a central OS Server.
- Consequently, when the central server fails or is taken offline for maintenance, local single stations continue displaying and acknowledging alarms locally, but those local historical events are NOT automatically replicated into the central server's WinCC SQL database upon restoration.
Synchronization via SIMATIC Process Historian (PH):
- SIMATIC Process Historian acts as the central, plant-wide repository for long-term archiving.
- Both the central OS Server and all decentralized Single-Station OS nodes are configured as PH data sources.
- During runtime, each node forwards its local alarm messages and tag archives to the Process Historian in real time.
- If network connectivity to the PH is interrupted (or when a station operates autonomously), the local node buffers historical data on its local hard drive. Upon reconnection, the buffered data is uploaded and merged into the Process Historian database, ensuring an unbroken, plant-wide historical audit trail.

Step-by-Step Implementation Procedure

Follow these steps to configure a hybrid PCS 7 architecture with unified alarm archiving:

Configure Network Topology in NetPro:
- In SIMATIC Manager Component View, configure the Industrial Ethernet Plant Bus connecting all S7-400 controllers, the central OS Server, and local Single Stations.
- Establish named S7 connections from the Central OS Server to all automation stations.
- Establish named S7 connections from each Single-Station OS to its respective local controller.
- Configure a separate Terminal Bus connecting the Central OS Server to its central OS Clients.
Partition Plant Hierarchy and Picture Assignment:
- Structure the Plant Hierarchy in SIMATIC Manager into distinct operational areas (e.g., Area 1, Area 2, Area 3).
- Assign Area 1 pictures to the Area 1 Single-Station OS project.
- Assign all area pictures to the Central OS Server project.
- Execute 'Options > Plant Hierarchy > Create/update block icons' for both the single stations and the central server.
Compile Automation Stations and OS Nodes:
- Execute AS-OS compilations for each local Single Station, selecting only the relevant controller programs.
- Execute an AS-OS compilation for the Central OS Server, selecting all plant controllers.
Configure Process Historian as Common Archive:
- Install and configure SIMATIC Process Historian (PH) on a dedicated industrial server.
- In SIMATIC Manager, add the Process Historian object to the multiproject.
- In the Object Properties of the Central OS Server, open the 'Options' tab and enable archiving to Process Historian.
- In the Object Properties of each Single-Station OS, enable archiving to the same Process Historian instance.
Verify Buffer Configuration for Autonomous Nodes:
- On each Single-Station OS, open WinCC Explorer > Process Historian configuration.
- Ensure the local store-and-forward buffer directory is configured with sufficient disk space (minimum 20 GB recommended) to cache historical alarms during disconnected operation.
Download and Commission Stations:
- Download the target OS projects to their respective single-station hardware and central server.
- Start runtime on all stations.

Verification

Verify central supervision: confirm that the Central OS Server and its clients display live data and alarms from all plant areas.
Verify local autonomy: isolate the Central OS Server by disconnecting its network cables. Confirm that local Single-Station OS nodes continue operating, displaying alarms, and logging trends for their respective areas without interruption.
Verify alarm buffering: while the central server is disconnected, generate process alarms in Area 1 and acknowledge them on the Area 1 Single Station.
Restore network connectivity to the central server: open the Process Historian Information Server (PH-IS) web portal.
Verify that all alarms generated on the local single station during the outage appear in the central historical log with precise controller timestamps.

Limitations and Operational Precautions

Operating independent Single-Station OS nodes alongside a central server increases engineering complexity and hardware licensing costs, as each Single Station requires independent AS RT PO and OS RT PO allocations. Concurrent operator control commands from both the central client and the local single station must be arbitrated using software interlocks or operator authorization levels to prevent conflicting process commands. Software licensing and hardware architecture options should be validated through an authorized Siemens distributor or the Siemens Industry Mall.

Engineer FAQ

Can WinCC Redundancy synchronize alarms between a Single Station and a Central Server?

No. WinCC Redundancy functions exclusively between paired redundant OS servers sharing a common project; it cannot synchronize data between independent OS projects.

How are historical alarms consolidated across independent stations?

By deploying SIMATIC Process Historian (PH). Both the central server and local single stations forward their alarms to PH, which acts as the unified long-term repository.

Can a local Single Station take over control if the Central OS Server fails?

Yes. Because the Single Station maintains its own direct S7 connection to the controller, it continues operating independently regardless of central server health.

Do Single Stations require separate OS Runtime licenses?

Yes. Each Single Station is an independent WinCC runtime station requiring its own OS Runtime Process Object (PO) license.

What prevents operator conflicts between local stations and central clients?

Control priorities can be enforced using WinCC user permissions, area authorizations, or interlocking logic in CFC (e.g., local/remote selector switches).