Accessing System Tags in WinCC Unified Scheduled Tasks

1. Problem Statement: System Tags Are Invisible to Server-Side Tasks

When configuring a WinCC Unified Runtime project on a SIMATIC Unified Comfort Panel (UCP) or a Unified PC Runtime, engineers frequently attempt to read a built-in system tag such as @UserName from inside a Scheduled Task whose trigger is set to the Update event. The intent is straightforward: poll the tag at a fixed interval (for example 5 s) and copy its value into an internal HMI tag that the rest of the project can consume.

At runtime the script fails. The trace viewer that the Unified engineering tools expose under Diagnostics > Traces reports that the tag @UserName does not exist, and the scheduled task logs a quality code of Bad for the read. The same script, moved into a button-click event on a screen, executes without errors and returns the expected value. This contradiction is the symptom of an architectural constraint, not a bug in the script.

2. Architecture: Server-Side Tasks vs. Client-Side Sessions

WinCC Unified Runtime separates two execution contexts that engineers must keep distinct when designing tag logic.

A Unified Comfort Panel can host multiple concurrent client sessions when it is reached through a Web Client or a secondary connection. Each session can be logged in with a different user and therefore has its own value for the session-local system tags. The scheduled task, by contrast, runs once per panel in the server context; it has no user and no client session attached to it. @UserName is therefore not bound when the task fires, and any read of that tag inside the script returns a missing-tag error.

Buttons are different: a button is always part of a screen instance that exists inside a specific client session. When the operator clicks the button, the event handler runs in that session context and can read @UserName because the session is the one that owns the logged-in user. This is the reason a script that works in a button event can fail in a scheduled task on the very same project.

3. Catalog of Session-Local vs. Server-Side System Tags

The following table lists the WinCC Unified system tags that are most commonly mistaken for server-side tags. Tags marked session-local cannot be read reliably from a scheduled task; tags marked server-side are safe to use in scheduled tasks.

4. Root Cause Analysis

The scheduled task runner is implemented as a server-side service that does not carry a UMC (Unified Management Console) session. Session-local system tags are populated by the client session manager the moment a user authenticates against the runtime. When the scheduled task fires, no client session has been attached to the read request, so the tag resolver cannot resolve @UserName.

This is by design: the same panel can host up to the licensed number of simultaneous Web Clients, each with its own user, and the runtime must not arbitrarily pick one of them when a server-side task queries a session-local variable. If the runtime were to return any value at all (for example, the last cached user name), the project would silently ship incorrect authorization context to PLC logic, which is a far more dangerous failure mode than a missing-tag error.

The Update 2 firmware release for Unified Comfort Panels (V19.0.0.2 and later) addresses part of this issue by adding explicit guard behavior: where the runtime cannot guarantee the meaning of a system tag inside a scheduled task, it returns Bad quality rather than caching the last value. This is the change that the field discussion refers to when it says the "last user name" remains in the IO field after logoff - in the older V19 GA build, the tag was being cached in some flows, which produced the symptom of an apparently working but actually stale value.

5. Firmware Update 2 Status and Verification

The Update 2 firmware package is published on the Siemens Industry Online Support portal. Reference the official entry SIMATIC WinCC Unified Comfort Panels - Update 2 (V19 Upd 2) for the build number, change log, and download instructions for the panel image.

To verify the firmware level that is currently installed on a UCP:

1. Open the panel's Control Panel (start menu, "Control Panel" on UCP).
2. Navigate to System > About & Help.
3. Read the Firmware version and the Image version fields. V19.0.0.2 or later means Update 2 is applied.

If the installation of the Update 2 executable opens a console window that logs to .../.../.../logfiles/setup/ucp-robocopy.log, this is the standard UCP setup pipeline running. ucp-robocopy is the helper binary that copies the new image onto the panel during the upgrade; its log is intended for Siemens support and can be ignored on a successful install. The path written by the installer reflects the temporary extraction directory used by the updater, not the final installation target.

6. Workaround 1: Base-Screen Timer Script

The most robust workaround moves the read from the server-side scheduled task into a client-side script that is bound to the active session. The pattern is:

1. Open the project's base screen (or any screen that is permanently present in the navigation model) in the TIA Portal editor.
2. Add a JavaScript action (Unified supports JavaScript, not VBScript) named for example usr_poll_user.
3. Bind the script to the screen's Loaded event. From the Loaded event, schedule a recurring call using setInterval with a 5 000 ms period.
4. In the script body, read Tags("@UserName").Read() and write the result into an internal HMI tag such as SessionUserName.

// JavaScript executed in the Loaded event of the base screen.
// Requires "Global definition" to be set: var pollHandle = null;

if (pollHandle === null) {
  pollHandle = setInterval(function () {
    var user = Tags("@UserName").Read();
    Tags("SessionUserName").Write(user);
  }, 5000);
}

Because the script lives inside a screen, it runs in the client session and can read @UserName reliably. The SessionUserName tag is a regular internal HMI tag and can be used as the trigger source for any scheduled task that needs the user context.

7. Workaround 2: Hide the IO Field When the Session Is Empty

A common follow-on problem: after the operator logs off, @UserName keeps the last value and the IO field still shows the old name. This is independent of the scheduled task issue and is caused by the tag's default update behavior on logoff. The fix is to bind the IO field's Visibility animation to a condition that includes the user-name quality.

// Read the tag with its quality object.
var userItem = Tags("@UserName");
var q = userItem.Read().Quality;   // 0 = Good, non-zero = Bad / Uncertain

// Make the IO field invisible when quality is anything but Good.
Screen.Items("UserNameField").Visible = (q === 0);

Apply the same script in a base screen timer so that the visibility flips on logoff without operator action. This complements the polling script from section 6 and avoids the visual confusion of a stale name.

8. Workaround 3: Drive a Scheduled Task from a Tag Trigger

Where the polling logic must remain in a scheduled task (for example, to write the user context to a PLC every cycle), the recommended pattern is to combine Workaround 1 with a tag-triggered scheduled task.

1. Create an internal HMI tag UserNameChanged of type Bool.
2. In the base screen script, set UserNameChanged to true whenever the polled SessionUserName value changes, then back to false after the scheduled task reads it.
3. Configure the scheduled task with the Tags trigger as described in the official TIA Portal V20 documentation Creating tasks with the "Tags" trigger (RT Unified).
4. Inside the task, read SessionUserName (not @UserName) and forward it to the PLC.

This decouples the trigger (a tag change) from the value source (a session-local copy) and lets the scheduled task remain in the server context while still receiving user data that is meaningful for the active session.

9. Workaround 4: Day/Time Trigger for Periodic PLC Writes

If the goal is simply to refresh a PLC register every 5 s, a day/time triggered scheduled task remains the correct tool, and the script should avoid reading session-local tags entirely. The server context owns @Date, @Time, @RunSeconds, and any process tag, so a periodic write to the PLC is a straight read-modify-write on those values.

// Scheduled task with Day/Time trigger, period 5 s.
var t = Tags("@Time").Read();
Tags("PlcCtrl").Write({
  TimeStamp: t,
  CycleNo: (Tags("CycleNo").Read() + 1)
});

If the application must ship user context to the PLC every 5 s, the polling script from section 6 should populate SessionUserName continuously and the scheduled task should read SessionUserName instead of @UserName.

10. Project Configuration Checklist

Before commissioning a Unified Runtime project that uses scheduled tasks with system tags, walk through the following list.

1. Confirm the firmware level of the UCP (V19.0.0.2 or later for Update 2 behavior).
2. Confirm the TIA Portal project version (V17, V18, V19, or V20) and consult the matching system tag reference in the TIA Portal help.
3. For each system tag the project uses, classify it as session-local or server-side using the table in section 3.
4. For any session-local tag, plan a base-screen polling script as the data source for server-side consumers.
5. For IO fields bound to @UserName or @CurrentScreen, add a quality-based visibility animation.
6. Test with at least two concurrent Web Client sessions to confirm the script reads the correct user per session.
7. Enable trace logging on the runtime (Runtime settings > Trace) and reproduce the failing path to capture the tag-not-found error.

11. Verification Procedure

After applying a workaround, run the following verification steps in the running Unified Runtime.

1. Log on to the panel as user Operator1. Open the trace viewer on the engineering station and start a live trace on the Tags category.
2. Confirm that SessionUserName updates to "Operator1" within 5 s of login.
3. Log off and wait 10 s. Confirm that the IO field bound to @UserName is hidden and that SessionUserName is empty (or contains the empty string, depending on tag configuration).
4. Open a Web Client in a second browser session and log in as Operator2. Confirm that the panel's SessionUserName (panel session) is unchanged and that the Web Client's SessionUserName shows "Operator2".
5. Trigger the tag-triggered scheduled task and verify in the trace that the PLC write carries the correct SessionUserName for the session that triggered it.

12. Troubleshooting Matrix

13. Cross-Platform Notes

Unified PC Runtime inherits the same scheduled-task semantics, but with an important twist: the PC Runtime can host a far larger number of Web Clients (depending on the license key) and the discrepancy between session-local and server-side reads is therefore more visible. A common production deployment has one PC Runtime serving five to thirty Web Clients; if any project under that PC reads @UserName from a scheduled task, the script is reading a value that does not exist for the server context, and the trace will show it on every cycle.

When migrating a WinCC Comfort (TIA Portal V13-V16) project to WinCC Unified, audit the legacy VBScript for direct references to internal runtime variables that previously worked. Comfort's scheduled tasks executed in a single implicit session, so the migration can mask the architectural change until the new project is commissioned with multiple users.

14. FAQ