WinCC Server-Server Communication: Configuring Multi-Plant HMI

Overview: Multi-Plant Visualization with WinCC

Large industrial operations frequently span multiple physical sites, each with its own dedicated SCADA server, yet operators and engineers often need a consolidated view across plants from a single engineering room, control center, or supervisory workstation. Siemens SIMATIC WinCC provides a native Server-Server communication mechanism (sometimes called server-server or distributed server architecture) that allows one WinCC server to read tags, archives, and messages from up to twelve other WinCC servers or redundant server pairs, and to display them on a single HMI client surface without requiring a parallel OPC UA infrastructure.

The fundamental question this design solves is: Can a WinCC station that already functions as a server for its own plant also act as a client to other remote WinCC servers? The answer is yes. The server performing the remote access behaves as a client in terms of configuration and runtime operation, but retains its full WinCC Server license rights for its local plant. This article walks through the licensing, project engineering, runtime configuration, and verification steps required to deploy this architecture on both WinCC V7 (Classic) and WinCC Professional (TIA Portal) platforms.

Architectural Topology

For a typical three-plant deployment, the topology looks like this:

• Plant A WinCC Server (Plant_A_SRV) — owns its own PLCs, tags, archives, and operator pictures.
• Plant B WinCC Server (Plant_B_SRV) — independent server with its own license and quantity structure.
• Plant C WinCC Server (Plant_C_SRV) — independent server with its own license and quantity structure.
• Plant C Operator Station — runs WinCC Runtime as both the local Plant C server and a client to Plant A and Plant B via server-server communication. This is sometimes called a "combined Server/Client" or "Server-as-Client" configuration.

Each of the three servers is an independent WinCC project with its own SQL-based archive database, its own Alarm Logging, and its own Tag Logging. Server-server communication does not merge the archives; it provides read access to the remote server's configured tag interface (the "Server Package"). The local server at Plant C then exposes those remote tags to its own local picture set, Alarm Logging, and Tag Logging — meaning local scripts, faceplates, and trends can consume remote-plant data with no extra gateway layer.

Licensing Prerequisites

Server-server communication has very specific licensing rules. Misreading them is the single most common reason a deployment fails at runtime with a "no license found" or "invalid package" error.

From the official Siemens WinCC Client/Server Option manual (PDF): "One server is capable to access the data from up to twelve other servers or redundant pairs of servers. The server accessing the data behaves as a client in respect of the configuration and operation, except that a standard server cannot be configured." Note the limit: 12 remote servers or redundant pairs. For a 3-plant deployment this is well within budget, but it must be planned if you anticipate scaling.

Software and Firmware Prerequisites

• WinCC V7.x (Classic): WinCC V7.4 SP1 or later is recommended for current support windows. The Server-Server scenario is part of the Client/Server option and requires the WinCC Server base package plus a sufficient PowerPack or client count.
• WinCC Professional (TIA Portal): For TIA Portal V17 and later, server-server communication is configured as a Multi-user system with multiple HMI devices. See the Multi-user system (RT Professional) documentation in TIA Portal V21 for the canonical reference.
• Operating system: Windows Server 2019 / 2022 (Standard or Datacenter) for the WinCC server role. Windows 10 / 11 LTSC is permitted only for engineering stations and small client stations.
• SQL Server: Bundled Microsoft SQL Server instance installed with WinCC (WinCC V7 installs SQL Server 2019 in current SPs). Archive databases are stored locally on each server.
• Network: TCP/IP connectivity on the WinCC port range (default 1024-65535 dynamic allocation for OPC, plus the configured WinCC project port). The official manual notes: "There is no time synchronization between server and clients. Archiving takes place centrally on one computer and this means that all of [the data is]..." — meaning each server timestamps its own archives independently.

Step-by-Step Configuration (WinCC V7)

1. Export the Server Package from each Remote Server

1. On Plant A server, open the WinCC Explorer in the Plant_A_SRV project.
2. Right-click on Server Data and select Server Package → Create.
3. WinCC compiles a self-contained .pck file containing the tag interface, message configuration, and picture references. Default location: \<project>\<server>\Packages\<ServerName>.pck.
4. Repeat on Plant B server to produce Plant_B_SRV.pck.
5. Copy both .pck files via network share or USB to Plant C's WinCC project directory, subfolder \Packages\.

2. Import and Register the Server Package on the Accessing Server

1. On Plant C server, open the Plant_C_SRV project in WinCC Explorer.
2. Right-click Server Data → Server Package → Load.
3. Select each .pck file and confirm. WinCC registers the remote server and adds its exported tags to the local namespace prefixed by the server name, e.g. Plant_A_SRV::Temperature_Tank_01 or simply ::Temperature_Tank_01 when the server context is already current.
4. Verify the tags appear in the WinCC tag manager. Each remote tag is shown with a yellow icon overlay indicating the server-server origin.

3. Configure the OS Project Editor and Quantity Structure

1. Open OS Project Editor from the WinCC Explorer start page (button on the right-hand pane).
2. Navigate to the Server tab.
3. Tick the checkbox "Use Server-Server communication".
4. Set the Number of servers field to 2 (Plant A and Plant B). The maximum permitted value is 12.
5. Click Apply. The OS Project Editor regenerates the @ system pictures and updates the WinCC_StationType registry entries.

4. Activate the Plant C Server with the Combined Role

1. In WinCC Explorer, click the Activate button on the toolbar (or right-click the project root → Activate).
2. Verify in the WinCC Runtime window: the local Plant C tags show real-time values and the imported Plant A and Plant B tags show values pulled from the remote servers.
3. Open Diagnostics → System Diagnostics to confirm that the remote server connections are listed in the Connections view with status Connected (green) rather than Fault (red).

Step-by-Step Configuration (WinCC Professional / TIA Portal V21)

The TIA Portal workflow is structurally similar but lives inside the project tree rather than the WinCC Explorer.

1. Open the TIA Portal project containing the HMI devices for all three plants.
2. In the project tree, add an HMI device for each plant server (e.g. Plant_A_RT, Plant_B_RT, Plant_C_RT) under HMI → Add new device → SIMATIC WinCC Runtime Professional.
3. On the Plant C HMI device, open Properties → Multi-user system and enable Server-side interface.
4. Add Plant A and Plant B as remote servers in the multi-user system editor. According to the TIA Portal V21 multi-user system documentation: "The client-server technology makes it possible to easily separate WinCC clients from the WinCC server: Configure your project centrally in the TIA Portal on the engineering station."
5. Compile the HMI devices and download the project to the Plant C runtime.
6. Activate runtime. The local server window and the remote plant picture set coexist in the same process tree.

Performance Considerations

Running a WinCC server and acting as a client to other servers on the same machine is a deliberate performance trade-off. The official WinCC V7 documentation and field experience converge on the following guidance:

Alternative Architecture: Dedicated Multi-Client

When the Plant C server is already heavily loaded, the recommended fallback is to deploy a WinCC Multi-Client on a separate operator station. The multi-client is a pure read-only viewer that connects to one or more WinCC servers in parallel and presents a unified picture set. Advantages:

• No additional license load on the Plant C server (it remains a pure server).
• Operator station can fail without affecting Plant C's own server role.
• Multi-client supports picture caching, which reduces server load by 40-70% during navigation-heavy sessions.

Disadvantages: an additional PC, OS, and SQL client license; tag scope must be re-managed in a second station. For green-field deployments with more than 4 plants, the multi-client approach scales better than stacking server-server roles.

Time Synchronization, Archiving, and Redundancy

The Client/Server Option manual states: "There is no time synchronization between server and clients. Archiving takes place centrally on one computer and this means that all of [the archives live on the server]." Implications:

• Each WinCC server timestamps its own messages and archives using its local system clock. You must deploy a domain time source (NTP) and synchronize every server to it — without this, alarm sequences across plants will appear scrambled in a multi-plant overview.
• Archive data is not mirrored automatically. If Plant C needs to trend data from Plant A, the trend pulls live values from Plant A's runtime; the historical trend display is generated from Plant A's archive database. Plant C does not duplicate Plant A's archives locally.
• For redundant pairs, configure WinCC Redundancy on each pair before enabling server-server communication. A redundant pair counts as one entry in the OS Project Editor's server count.

Verification Checklist

1. On Plant C, open WinCC Explorer → Tools → Status of Server Connections. Confirm Plant A and Plant B are listed with state Connected.
2. Open a local Plant C picture that uses a tag from Plant A. Verify the value updates within one refresh cycle (default 1 s; configurable in the tag properties).
3. Trigger an alarm on Plant A. Verify the alarm appears in Plant C's Alarm Logging within 2 s of being raised on Plant A.
4. Open a trend window that includes a remote tag. Verify the trend retrieves historical data from Plant A's SQL archive (not a blank chart).
5. Stop the Plant A WinCC Runtime. Plant C should report the connection state as Fault within 5 s and operator picture should display the configured substitute value or "connection lost" badge.
6. Restart Plant A. Verify automatic reconnection within 30 s without operator intervention.

Troubleshooting Matrix

Security and Network Hardening

Server-server communication is encrypted at the WinCC application layer (TLS 1.2 in V7.4 SP1+), but the underlying DCOM and OPC Classic channels remain a target. Best practices:

• Isolate WinCC server traffic on a dedicated VLAN (e.g. VLAN 200) separate from the corporate LAN.
• Disable SMBv1 on all servers; restrict admin$ and C$ shares to the WinCC engineering account.
• Apply the Siemens WinCC Security Configuration checklist: enable DCOM authentication, restrict launch permissions to the WinCC service account, and disable anonymous RPC.
• Audit the WinCC project for hard-coded credentials; migrate to the WinCC User Administrator with role-based access (Operator / Engineer / Administrator).
• For multi-plant sites with regulatory exposure (IEC 62443), evaluate WinCC Unified as a replacement for WinCC V7 — Unified's native OPC UA server-server communication requires no DCOM and is profile-conformant.

FAQ