WinCC Unified V17: Active User Display and Remote Logoff

1. Overview: WinCC Unified V17 User Session Visibility

WinCC Unified V17 (TIA Portal V17 / WinCC Unified PC V17) exposes a centralized user administration model that covers both the Engineering System and the Runtime. Operators, administrators, and HMI users authenticate against a project-wide user administration database, and the web-based Runtime (Unified Collaboration / Unified Web Client) tracks each active session on the server side. The question most engineers raise in V17 is: how do I see who is currently connected, and how do I force a session to end as administrator?

The V17 Runtime provides a small but reliable set of system functions, JavaScript APIs, and configuration switches that allow a project to:

• Display the currently logged-in user on a screen.
• Enumerate the number of active web clients (counting sessions, not just unique users).
• Terminate a specific user session or all sessions from a privileged client.
• Surface server-side Runtime status (Running / Partly running / Stopped) on a diagnostic screen.

There is no built-in "status.html" page shipped with WinCC Unified V17 that lists every web session, but the building blocks to produce an equivalent operator page are available in the standard scripting API and the WinCC Unified Performance & Diagnostics toolset.

2. WinCC Unified V17 Architecture and User Model

WinCC Unified V17 introduces a unified user model that replaces the older WinCC Comfort/Advanced and WinCC Professional user administration. The model is described in the TIA Portal V17 Help under "WinCC Unified - User administration" and is implemented on the server side by the UMC (User Management Component) service.

Every successful login generates a session token that is stored on the server. The session timeout and the maximum number of sessions are configurable parameters in the Runtime settings dialog.

2.1 Key Runtime Settings

Open the project in TIA Portal V17, navigate to Runtime settings → User administration and configure the following:

• Session timeout (min): Default 30 minutes. Idle sessions are invalidated after this period.
• Maximum sessions: Determines how many concurrent web clients can log in. Exceeding this count will block new logins, not terminate existing ones.
• Permit automatic logoff: When enabled, an administrator-level client can call the LogoffUser system function against any session.
• Encrypt communication (TLS): Required for production deployments if remote logoff over the network is to be performed.

3. System Functions for Reading the Current User

WinCC Unified V17 exposes the current user through the System functions palette under "User administration". The two most commonly used functions are:

3.1 Wiring the current user to an I/O Field

1. Drag an I/O Field onto the screen.
2. Set Mode = "Output".
3. Bind the process tag to an internal string tag CurrentUser (length 64 recommended).
4. Add a "Load user" event on the screen's Loaded event using the system function GetCurrentUserName and write the result to CurrentUser.
5. Optionally trigger a 5-second scheduled task to refresh the value for long-running screens.

This produces the visual effect shown in many customer samples: the operator name in the top bar of the HMI screen, updated at every navigation event.

4. Listing All Active Web Users (Session Count)

V17 does not expose "all logged-in users" as a single system function on the client side, but it is reachable through three different approaches depending on the engineering scope.

4.1 Approach A – UMC REST API call from a custom web control

The UMC service on port 4001 exposes session information via REST. A custom web control inside the Unified project can issue a GET request and parse the JSON response:

GET https://<server>:4001/umc/api/sessions
Authorization: Bearer <admin_token>
Accept: application/json

Sample response shape (truncated):

{
  "sessions": [
    { "id": "s-7f3a", "user": "operator1", "client": "10.0.4.22", "loggedIn": "2024-08-12T09:14:02Z" },
    { "id": "s-7f3b", "user": "admin",     "client": "10.0.4.5",  "loggedIn": "2024-08-12T09:15:48Z" }
  ]
}

This is the only API that exposes the full session list with IP, login timestamp, and session ID, which is exactly what is needed for the "remote logoff" workflow described in Section 5.

4.2 Approach B – WinCC Unified Performance & Diagnostics

The WinCC Unified Performance & Diagnostics tool (separate installation, available on the SIMATIC WinCC Unified DVD image) provides a built-in "Active sessions" view under Diagnostics → User sessions. It is intended for administrators and is read-only.

4.3 Approach C – Local tag from a scheduled VBScript

On the Runtime server, schedule a VBScript or PowerShell script that queries the UMC database (SQLite by default) and writes the count into an internal tag through OPC UA. Use this approach only on dedicated engineering stations, never on the production HMI server.

5. Implementing Remote Logoff with Admin Rights

Two distinct use cases exist:

1. Self-logoff: The currently authenticated user wants to log out. Use the built-in Logoff system function wired to a button.
2. Administrative logoff of another user: An administrator with the HMI Administration right must terminate a different session. This requires elevated UMC rights and a separate API call.

5.1 Self-logoff

On a button's Click event add the system function Logoff. The Unified client returns to the login screen. This is the same behavior described in the official WinCC Unified V17 help under "Logging the user off".

5.2 Administrative remote logoff via UMC REST API

Because V17 does not ship a graphical "kick user" dialog, a custom web control or a small WinCC Unified script is the canonical implementation. The flow is:

1. The administrator authenticates against the UMC endpoint and obtains a bearer token: POST /umc/api/auth/token.
2. The administrator queries GET /umc/api/sessions and selects the target id.
3. The administrator issues DELETE /umc/api/sessions/{id}.
4. The target client is disconnected within approximately 2-5 seconds; any unsaved input is lost.

5.3 Sample JavaScript inside a Unified Web Control

async function kickSession(sessionId) {
  const token = await getAdminToken();
  const resp = await fetch(
    `https://${location.hostname}:4001/umc/api/sessions/${sessionId}`,
    {
      method: 'DELETE',
      headers: {
        'Authorization': 'Bearer ' + token,
        'Accept': 'application/json'
      }
    }
  );
  if (resp.ok) {
    HMIRuntime.Trace('Session terminated: ' + sessionId);
    refreshSessionList();
  } else {
    HMIRuntime.Trace('Terminate failed: ' + resp.status);
  }
}

Wrap the kickSession call in a button that is enabled only when the current user has the HMI Administration role. This keeps the administrative capability inside the configured security model and produces an auditable trace entry.

6. Web Server Status and Diagnostic Pages

WinCC Unified V17 does not include a public "status.html" page. The closest built-in capabilities are:

For a customer-facing status page, build a small Unified screen that displays:

• Number of currently active web sessions (count from the UMC REST call).
• List of usernames with last activity timestamp.
• Project status (Running / Partly running / Stopped) read from the Runtime.State system tag.
• License consumption gauge (see Section 7).

7. Licensing Impact and User Counting

WinCC Unified V17 counts concurrent web clients, not named users. The relevant license types are:

• WinCC Unified PC Runtime (16 / 64 / 128 / 256 / 512 / 1024 / 2048 / 4096 / 8192 / 16384 PowerTags): Base Runtime license.
• WinCC Unified Web Client (1 / 5 / 10 / 25 / 50 / 100 / 250 / 500): Counts each concurrent web session.
• WinCC Unified Read-only Web Client: For display-only HMIs (does not support logoff workflows).

A practical license monitoring screen reads the UMC session count and compares it to the licensed pool. When the count reaches the licensed maximum, new logins are rejected with the error "Maximum number of users reached" and the UMC returns HTTP 429 on /umc/api/auth/token.

8. Security Considerations and Audit Trail

• Role-based access: Place all session-management functions behind a dedicated "Administrator" role. Avoid using the default Administrator group for daily work.
• Auditing: Enable the UMC audit log (Runtime settings → User administration → "Log user changes"). Each logoff action is recorded with user, target session ID, and timestamp.
• Transport encryption: Activate TLS on the web server (Runtime settings → "Web server") and on the UMC endpoint. Self-signed certificates are acceptable for isolated cells; for multi-site deployments use certificates issued by a corporate CA.
• Password policy: Configure the password policy under "User administration → Password policy": minimum length 10, complexity 3 of 4, rotation 90 days. This is enforced from V17 Update 2 onward.
• Idle and absolute timeout: Set both an idle timeout (e.g. 15 min) and an absolute timeout (e.g. 8 h) to limit the impact of an unattended browser session.

9. Troubleshooting Matrix

10. Verification Checklist

After implementing the user-display and remote-logoff workflow, validate the following items on a test Runtime:

1. Two browsers (Chrome, Edge) log in as different users; both names appear on the diagnostic screen.
2. The session count matches the number of currently authenticated clients (including redundant server-side connections).
3. An administrator using a third browser can terminate one of the other two sessions; the affected tab returns to the login screen within 5 seconds.
4. The UMC audit log contains an entry for the administrative logoff.
5. Reducing the Web Client license count below the current session count causes new logins to be rejected while existing sessions remain active.
6. Setting the project to "Partly running" reproduces the documented behavior; the system tag Runtime.State reports the partial state and the UMC log records an authorization failure. Reference: Notes on use - WinCC Unified PC.