WinCC Separate Client Project Configuration and Performance

Overview: WinCC Client-Server Architecture and the Separate Client Project

Siemens WinCC supports two fundamentally different client deployment models: the shared (load-on-demand) client in which clients open the server project's pictures and tag database directly over the network, and the separate client project in which each client maintains its own WinCC Explorer project, loads only the data it needs at startup, and renders pictures locally. The choice between these two models has direct consequences for start-up time, picture-update performance, server CPU/RAM load, network bandwidth, and the ability to deploy independent client-specific configurations (different languages, alarm filters, user rights, or hotkeys).

In WinCC V7.x (classic) and WinCC V8.x (current), separate client projects are created from WinCC Explorer > File > New > Client Project. In TIA Portal WinCC Professional / WinCC RT Professional, the equivalent configuration is implemented through the multi-user system project mode, where the client device is added to the HMI project tree as a separate device with its own images, scripts, and connection configuration that references the central server project. The same architectural separation principle applies across both generations: server data is consumed by reference, while runtime artifacts (graphics, VB/C scripts, local tags) live on the client.

Field experience shows the separate client project model is most beneficial when (a) the number of clients exceeds 4-6, (b) picture load times over WAN/VLAN links exceed 3-5 seconds, (c) the operator stations use complex Graphics Designer pictures with many dynamic dialogs, or (d) redundant servers must be hot-swapped without dropping the client picture cache. The shared model is acceptable for tightly coupled LAN installations with 2-4 clients and modest picture complexity.

Architectural Comparison: Shared Client vs. Separate Client Project

Before committing to one model, evaluate the technical trade-offs across the following dimensions. This matrix is derived from the documented behavior of WinCC V7.5/V7.4 SP3 and WinCC V8.1, including the multi-user system guidance in the official Siemens documentation library.

Prerequisites and Licensing

Before creating a separate client project, verify the following prerequisites on every machine involved:

• Operating System: Windows Server 2019 / 2022 (or Windows 10/11 LTSC for engineering stations) matching the WinCC version's compatibility matrix.
• WinCC Version: WinCC V7.4 SP3, V7.5, V7.5 SP1, V7.5 SP2, or V8.0/V8.1 (current at the time of writing). For mixed-version scenarios, the lowest common version governs.
• Licensing: Each separate client project requires a valid WinCC RT Client license (16, 64, 128, 256, 512, 1024, 2048, 4096, 8000 PowerTags, plus an RT Client base license per operator station). Redundant server operation additionally requires the WinCC/Redundancy option on both servers.
• User Rights: The user performing the configuration must be a member of the local SIMATIC HMI group on every client and server. The WinCC Project-Manager service account must have read/write access to the project directories and to \<server>\<project>$ shares.
• Network: Stable TCP/IP connectivity on port 445 (SMB) for project file access and the configured WinCC channel ports (default varies by driver, e.g., S7DOS channel uses ISO-on-TCP port 102, named connections use 49152-65535).
• Time Synchronization: All servers and clients must be within 1 second of a common NTP source; alarms and audit trails use timestamp arithmetic that breaks under drift.

Step-by-Step: Creating a Separate Client Project in WinCC V7/V8.1

1. Verify server project status. On the primary server, open WinCC Explorer and confirm the server project is in Runtime or closed cleanly. The server project must be the active configuration source for the client.
2. Configure server data for client distribution. In WinCC Explorer on the server, right-click Server Data and select Configure.... Add the server(s) the client is permitted to attach to (preferred server, standby server). Enable the Standard server option and assign the server's computer name exactly as resolved by DNS, including the case if NetBIOS is in use.
3. Prepare a project distribution share. Create a UNC share on the server, e.g., \<server>\WinCC_Projects$, granting Change rights to the SIMATIC HMI group. This share will hold the server package exported for the client.
4. Create the client project. On the client machine, launch WinCC Explorer. Select File > New > Client Project. Choose New (do not select Open against the server path). Specify the project path, ideally on the client's local SSD, e.g., D:\WinCC\Projects\Client01.
5. Assign the server data reference. In the new client project, right-click Server Data > Assign.... Point to the share from Step 3. WinCC will mount the server package and populate the client's tag references.
6. Copy the Graphics Designer pictures. On the server, locate the GraCS folder under the server project directory. Copy only the .PDL files actually referenced by the client's screen tree into the client's local <ClientProject>\GraCS directory. Do not copy the entire GraCS unless you intend to expose every picture.
7. Configure the startup list. In the client project's Computer > Startup, add Graphics Runtime, Alarm Logging Runtime, Tag Logging Runtime, Report Runtime, and Global Script Runtime in the order required for your sequence. Disable any startup element that is not used on the operator station (e.g., Report Runtime on a kiosk client).
8. Adjust client-specific parameters. Open Computer > Properties > Graphics Runtime. Set Window mode, Start Picture, Monitor assignment, and any Hotkeys that are operator-specific.
9. Configure redundancy behavior. In Computer > Redundancy, enable Partner server and enter the standby server's name. Set the Archive synchronization interval per your retention policy (typical: 60 s for tag logging, 300 s for alarm logging).
10. Activate and verify. Save the project. Right-click the project root and select Activate. Watch the WinCC service window for the line Server connection established to <servername>.

Multi-User System Equivalent in WinCC RT Professional (TIA Portal)

For installations engineered in TIA Portal V17 / V18 / V19 / V20 / V21 with WinCC Professional or WinCC RT Professional, the separate client concept is expressed through the multi-user system project mode. The official Siemens documentation describes this as the canonical way to operate several operator stations against one server project.

Per the TIA Portal V21 multi-user system documentation, the configuration steps are:

1. In the TIA Portal project tree, add an HMI device for the server (e.g., WinCC RT Professional Server) and one HMI device per client (e.g., WinCC RT Professional Client).
2. In the client device's Connections editor, add an HMI connection pointing to the server device. Set the Access point to S7ONLINE and the connection mode to Server-Client (multi-user).
3. Configure the client device's Runtime settings > General: enable Operate as server = No, enable Multi-user system.
4. Distribute the screen tree. In the server project, the screens are visible in the project navigator. Mark each screen to be loaded on a specific client via Right-click > Assign to client device, or use the Screen distribution table view introduced in V18.
5. Compile and download the client device. Each client receives its own compiled runtime, including only the screens and tags it references.

This approach is fully analogous to the WinCC V7 separate client project: the server hosts the central tag database and alarms, while each client renders its own copy of the assigned screens locally.

Performance Tuning: Eliminating 10-25 s Tag Update Delays

field reports reported tag update times of 10-25 seconds after a client connected to the server, even though the server alone was fast. This symptom has three common root causes; diagnose each in order.

Root Cause 1: C-Script on the Main Picture with High Frequency Trigger

Global Script C actions attached to the main process picture often re-evaluate on every tag change, every 250 ms, or every picture refresh. A script that contains SetTagFloat(...) calls or that reads/writes many internal tags in a tight loop will monopolize the WinCC script thread and starve the tag update queue.

Diagnostic: Open the WinCC service console on the server. Watch the Global Script thread counter. If it remains near saturation (e.g., 80%+ thread usage), suspect a script bottleneck.

Fix: Move per-tick logic into a scheduled cyclic trigger with a 500-1000 ms period rather than the On Change trigger. Replace SetTagFloat() calls with direct tag bindings in the Graphics Designer. Audit scripts with the WinCC script debugger (Global Script > Debug) to find the longest-running actions.

Root Cause 2: Excessive Picture Cache Invalidation

If a picture is configured as Always re-compile or contains many dynamic dialogs with cyclic recomputation, every server-side update forces picture delta push to all clients. Over a slow link, this dominates the channel.

Diagnostic: Run the WinCC Channel Diagnosis tool on both server and client. Observe Picture Cache Hit Ratio; below 85% indicates excessive invalidation.

Fix: Switch to the separate client project model so pictures render locally and tag updates only traverse the network. Reduce dynamic dialog refresh to On Change where possible, and move sub-second logic into a dedicated Trend or Online Table Control rather than text I/O fields.

Root Cause 3: Channel Connection Saturation

Each shared client multiplies the number of subscriptions on the S7 channel. With many tags polled via the SIMATIC S7-1200/S7-1500 channel on a single OPC UA or ISO-on-TCP connection, update rate degrades quadratically rather than linearly.

Diagnostic: In WinCC Channel Diagnosis, check Connection load per logical connection. Above 70% sustained load, the channel is the bottleneck.

Fix: Split tags across multiple S7 connections (separate connections per PLC, separate connections per CPU). For S7-1500, prefer the optimized SIMATIC S7-1500 channel over the legacy S7DOS channel when the controller firmware supports it (CPU firmware V2.0+). With the separate client project, each client subscribes only to the tags it actually displays, dramatically reducing the per-connection load.

Picture and Script Distribution Best Practices

When the separate client project model is deployed at scale, picture and script distribution becomes a recurring engineering task. Apply the following practices to minimize maintenance overhead and runtime drift between server and client packages.

• Versioned export. Always export the server package with a timestamped folder name (e.g., ServerPkg_20250115_1030) so a client can be reverted to a known-good configuration without affecting the server.
• Picture hashing. Maintain an MD5/SHA-256 hash of each .PDL file in a manifest. Distribute picture updates via a script (PowerShell or robocopy) that only overwrites changed files.
• Shared library pictures. Keep @[email protected] and @[email protected] system pictures on the client even if not explicitly referenced; the Graphics Designer requires them for navigation.
• Central C-script library. Store global C actions on the server under \<server>\<project>\library and reference them from each client project via Include. This avoids duplicating business logic.
• Alarm filter per client. Define client-specific alarm filters in the client project's Alarm Logging > Message Filters so each operator station shows only its responsibility area.
• User administration. Configure WinCC User Administrator on the server for the master user list; on the client, enable Use server user administration in Computer > Properties > User Administrator.

Redundancy and Failover Behavior with Separate Client Projects

In a WinCC redundant server pair (Server A preferred, Server B standby), both servers hold a synchronized copy of the runtime database. When the client's preferred server fails, the client automatically attempts to bind to the partner server within the configured Connection timeout (default 60 s).

For a separate client project, the failover is graceful because:

1. The client's local GraCS folder is untouched by the failover; pictures remain loaded.
2. Only the tag and alarm channel connections rebind to the partner server.
3. Archive synchronization between Server A and Server B continues in the background; tag values written during the failover window are reconciled once both servers reconnect.

For a shared client, the failover typically forces a picture reload because the client was reading pictures from the failed server's disk. This reload can take 10-60 seconds on a heavily loaded server - the separate client project model is therefore strongly recommended for redundant installations.

Verification Checklist After Deployment

After activating the separate client project and the server, run the following checks to confirm correct operation:

1. Tag update timing. Force a value change in the PLC (or via a test tag in the server). Confirm the client displays the new value within <2 s for cyclic tags and <500 ms for event-driven tags.
2. Picture load time. Stop the WinCC client runtime. Restart it. Confirm the main picture is fully rendered within 5 s (or whatever your acceptance criterion is).
3. Redundancy failover. Simulate a server failure by stopping the WinCC service on the preferred server. Confirm the client rebinds to the partner within the configured timeout and continues displaying live data.
4. Alarm acknowledgment. Trigger an alarm from the PLC. Confirm the alarm appears on the client within 1 s and that operator acknowledgment is written back to the server's alarm log.
5. User rights. Log in as a non-administrative operator. Confirm restricted picture navigation, restricted tag write access, and proper logout behavior.
6. Archive consistency. After a full shift of operation, export the tag archive from both servers and confirm identical timestamps and values.

Migration Path: Shared Client to Separate Client Project

Existing installations using the shared client model can be migrated to separate client projects with a planned engineering effort. The canonical migration sequence is:

1. Inventory the client stations: list their computer names, monitor configurations, and operator roles.
2. On the server, audit GraCS and identify which .PDL files each client actually displays. Use WinCC Explorer > Tools > Cross Reference to map tags to pictures.
3. Create a separate client project on each client machine as described in the step-by-step section above.
4. Copy only the required .PDL files into each client's local GraCS folder.
5. Schedule a maintenance window. Stop the existing shared clients. Activate the new separate client projects. Validate against the verification checklist.
6. Keep the server project unchanged throughout; the change is purely on the client side.

For installations with 10+ clients, automate the client provisioning using a deployment script that mounts the server package share, copies the assigned picture subset, and writes the client configuration file. Siemens ships SIMATIC WinCC Cross Reference and the WinCC Configuration Studio export functions specifically to support this kind of bulk deployment.

Field-Proven Caveats and Common Mistakes

• Don't copy WinCC.exe or DLLs to the client. The client must have a fully installed WinCC RT (or RT Client) with the same version and service pack as the server. Mixing binaries causes "library not found" or "project version mismatch" errors at start-up.
• Don't share the WinCC project directory across machines. Only the assigned subset should be on the client. Storing the entire server project on the client defeats the purpose and creates license ambiguity.
• Don't use DFS or replicated shares for the server package. File-locking under SMB is unreliable on DFS, and replication introduces latency in picture-version detection. Use a direct UNC path to the server's local disk.
• Don't disable Windows firewall without a plan. The WinCC client opens several high ports for the WinCC Channel and the OPC UA stack. Either open only the required ports or configure WinCC to use a fixed port range via Computer > Properties > WinCC Channel.
• Don't ignore the WinCC service account. Local System is acceptable for testing; for production, configure a domain service account in the SIMATIC HMI group. This is required for proper authentication across server and client.
• Don't skip the picture distribution manifest. Without a manifest, picture drift between server and client is the most common cause of "the picture looks different on this station" tickets.

References to Official Documentation

For further reading, the following official Siemens documentation entries are the authoritative references for the architectures described in this article:

• Client Project - WinCC V8.1: Working with WinCC (Entry ID 109976850)
• TIA Portal V21 - Multi-User System (RT Professional)