WinCC Global vs Local Scripts: Client-Server Execution Guide

Script execution context in a Siemens WinCC server-client runtime is one of the most commonly misunderstood areas of HMI engineering. A global script is not the same as a script that runs everywhere, and a local script is not the same as a script that runs only on the client. The actual execution model depends on three orthogonal factors: where the script is stored in the project tree, what triggers the script, and what type of tag or variable fired that trigger. This reference clarifies the model, explains how server-client propagation works, and provides a verified pattern for a per-station authorization script that does not cross-contaminate other clients.

1. Script Storage vs Script Execution Context

WinCC projects contain three primary script containers, and the location of a script determines how it can be called - but it does not, by itself, determine where it runs.

A script that lives in the global script editor is globally visible: any client or server in the project can reference it by name. A script that lives in a computer's Actions: Station list is visible only to that computer and never propagates. The execution site is governed by the trigger source, not by the storage location.

2. Trigger Types and Propagation

WinCC scripts run in response to a trigger. The two trigger categories you must distinguish are:

1. Project tag trigger - the tag is part of the project tag list and is replicated to every configured computer.
2. Computer-local tag trigger - the tag exists only on one specific computer and is not visible to the others.

When a project tag changes value, every computer that subscribed to that tag receives the update. If a global script is bound to that tag, every computer evaluates the change locally. The script body runs on each subscribed computer, not on a single shared engine.

When a computer-local tag changes, only the owning computer sees the change. A global script bound to that computer-local tag will only execute on the owning computer, because no other computer can ever observe the trigger event.

3. Server-Client Topology Model

The reference topology for this article is a single WinCC server hosting the project, with one or more WinCC clients connected as either standard clients or web clients. The server owns the canonical tag image; clients hold a redundant copy used for local screen updates.

In this topology, an action stored under Global Script and triggered by a project tag will run once on the server and once on each subscribed client. An action stored under Client 1 → Actions: Station will only run on Client 1 regardless of trigger type.

4. Execution Behavior Matrix

The table below maps the four practical combinations of (script location) x (trigger type) to the resulting execution footprint.

5. Cyclic vs Event-Triggered Execution

Every script action has a trigger configuration dialog. The trigger can be:

• Tag trigger - fires on value change or on a configurable threshold.
• Cyclic trigger - fires every N seconds, with a configurable time base (250 ms, 500 ms, 1 s, 5 s, 10 s, 1 min, 5 min, 10 min, 1 h, user-defined).
• Event trigger - picture open/close, keyboard event, mouse event, alarm event, language switch.

A cyclic trigger on a global script bound to a project tag is the highest-risk configuration: it will execute on the server and on every client at the configured interval, multiplying CPU load by the number of stations. For an eight-client system with a 1 s cyclic, you generate 9 script executions per second. For an authorization script that only needs to run once per login, this is wasteful and causes race conditions on the user-rights array.

6. Authorization Script Pattern (Per-Station)

The most common real-world use case is a per-station authorization routine that runs immediately after a user logs in on a particular client. The script inspects the current operator name, looks up group memberships, and writes the result into a computer-local internal tag set that the screen navigation uses to enable or disable buttons.

The correct implementation, in WinCC V7 VBScript inside a global script action, uses a computer-local tag as the trigger and writes only to computer-local authorization tags. The script body is identical on every station, but the trigger is local, so execution is local.

' Global Script action: Auth_RefreshLocalRights
' Trigger: Computer-local internal tag "@Local_LoginEvent" (rising edge, internal)
' Writes to computer-local tags: @Local_UserLevel, @Local_MaintAllowed, @Local_AdminAllowed

Dim sUser, iLevel
sUser = HMIRuntime.Tags("@CurrentUser").Read
iLevel = 0

Select Case UCase(sUser)
    Case "OPERATOR_A"   iLevel = 1
    Case "MAINT_USER"   iLevel = 2
    Case "ADMIN"        iLevel = 3
    Case Else           iLevel = 0
End Select

HMIRuntime.Tags("@Local_UserLevel").Write iLevel
HMIRuntime.Tags("@Local_MaintAllowed").Write (iLevel >= 2)
HMIRuntime.Tags("@Local_AdminAllowed").Write (iLevel >= 3)

The tags prefixed with @ are WinCC internal tags. @CurrentUser is a system tag and is replicated; the three @Local_* tags must be defined as computer-local internal tags in each client's tag management. When the user logs in on Client 2, only Client 2's @Local_LoginEvent changes, only Client 2's script instance fires, and only Client 2's authorization tags update.

7. Picture-Local Script Trigger Model

Scripts attached to picture objects (for example, the Click event of a button) run in the runtime context of the station that is currently displaying the picture. If the picture is the server's start picture, the script can only fire on the server. If the picture is replicated to all clients (which is the default for base screens in a distributed system), the script logic is replicated with it and will fire on whichever station the user clicks the button.

For an authentication button that opens a login window, the canonical pattern is:

1. Place a base picture LoginScreen.pdl on the server with a button "Login".
2. Replicate the picture to all clients via picture assignment.
3. On the button's Click event, call the global function OpenLoginWindow().
4. The function lives in the global script editor and uses HMIRuntime.Screens to open Login.pdl on the local station.

This pattern gives you a single copy of the screen logic but a station-local execution footprint - exactly the right behavior for per-station user logins.

8. TIA Portal V20 Runtime Unified Differences

In TIA Portal V20 Runtime Unified, the scripting model moves away from VBScript to JavaScript-based scripts and reorganizes the project tree. The concepts still map cleanly:

For Unified, the documentation describes a global definition inside a local script: when the global definition area of a global script is used, the script context in which the global script is executed is relevant. This means that a global function that references local data must be invoked from a script context that has access to that local data. The same trigger-propagation logic applies: a Unified global script bound to a local HMI tag fires only on the local HMI; bound to a shared tag, it fires on every subscribing runtime. See the official manual page Creating a global definition in a local script (RT Unified, V20) for the binding rules.

9. Best Practices Checklist

• Name by intent, not by location. Prefix actions that must run everywhere with Global_ and prefix per-station actions with Local_. Reviewers should be able to read the prefix and predict the execution footprint.
• Use computer-local internal tags as the trigger when you need per-station behavior. Do not rely on a project tag with conditional logic that early-returns unless the script is local-only by design.
• Keep authorization writes in computer-local tags. Never write a user-rights bit into a project tag that other clients will overwrite.
• Prefer event triggers over cyclic triggers for stateful operations. Cyclic scripts run even when nothing has changed and burn CPU on every station.
• Inspect the GSC Runtime window during commissioning. The GSC (Global Script C) and GSR (Global Script Runtime) tools list every action, its trigger, and its last execution timestamp. Use this to confirm the action is firing on the intended stations only.
• Document the trigger tag type. In a code comment, state whether the trigger is a project tag or a computer-local tag. The runtime will not warn you if you bind a global action to a project tag when the design intent was local.

10. Verification Procedure

After configuring any script that you expect to execute per station, verify the footprint with this procedure:

1. Open the GSC Runtime on the server and on one client.
2. Force the trigger tag to change on the test client (use the Tag Simulator or a button bound to the local tag).
3. Confirm the action's last-execution timestamp advances on the test client only.
4. Repeat on a second client to confirm the action does not fire there.
5. For a project-tag-triggered global action, perform a single tag change and confirm the timestamp advances on every station, including the server.

If a per-station action fires on multiple stations, the trigger tag is project-scoped - move it to the computer-local internal tags group. If a synchronized action fires on only one station, the trigger tag is local - re-evaluate whether you actually need global behavior.

11. Troubleshooting Matrix

12. Summary Decision Table