Resolving WinCC Unified PLC User Login on MTP1900 Panels

Modern plant operators with globally distributed HMI fleets increasingly require that user identity and authorization level be assigned by the control system rather than by an operator typing credentials into each panel. In brownfield installations where a Manufacturing Execution System (MES) is the system of record for operator identity (badge IDs, shift assignments, certification expiry), there is a strong engineering argument for letting the PLC - which already exchanges data with the MES - push a user identity into the HMI rather than expecting the operator to maintain a separate, manually-updated local user list on every Unified Comfort Panel.

This is the request that comes up routinely in TIA Portal V17, V18, V19, and V20 projects whenever a Comfort Panel is replaced with a Unified Comfort Panel such as the MTP700, MTP1000, MTP1200, MTP1500, or MTP1900. The original Comfort Panels exposed a jobmailbox mechanism that allowed the PLC to write a user number and an authorization level directly into the HMI runtime; the runtime would then surface that user as a "PLC user" with the assigned rights. The MTP generation does not have an equivalent published mechanism as of TIA Portal V19. Engineers who migrate from Comfort to Unified and need the same behavior hit a wall: there is no system function in the standard WinCC Unified toolbox that performs a programmatic user logon from a PLC tag, and there is no public, supported script that wraps the logon operation.

This article documents the current state of the platform, the engineering workarounds that are practical today, the S7-1500 / S7-1515F data block layout that the workarounds depend on, and the migration path engineers should plan for when they cannot wait for a future TIA release.

1. The Engineering Problem: Why the PLC Should Drive Identity

Three operational pressures converge on the request for PLC-driven login:

• Single source of truth for identity. The MES owns operator records, certification expiry dates, and shift assignments. Maintaining a parallel local user list on every HMI invites drift between the MES view of who is allowed to do what and the HMI view of the same.
• Global fleet consistency. Plants that deploy the same machine across regions often run different TIA Portal versions per site (V17 on older lines, V19 on new lines, V20 on pilot lines). A local HMI user list has to be maintained per site; an MES-driven identity tag is identical everywhere.
• Audit trail integrity. Regulated industries (pharma, food, medical devices) require that the operator identity attached to a production event be the same identity that was authorized by the system of record at the time the event occurred. A local HMI authentication that is not synchronized with the MES breaks the chain of custody.

The Comfort Panel jobmailbox solved all three pressures for the Comfort generation. The Unified generation does not, as of TIA V19 / V20, and the workaround has to be built explicitly.

2. Legacy Comfort Panel Jobmailbox Login Pattern

On the SIMATIC Comfort Panel line (TP700 Comfort, TP900 Comfort, TP1200 Comfort, TP1500 Comfort, TP1900 Comfort, TP2200 Comfort) the PLC could trigger user logon and logoff through a job mailbox. The job mailbox was a 16-word array of PLC tags that the panel polled at the configured acquisition cycle. Specific control word values (function IDs in the 1, 2, 4, 5, 6, 7 range) told the panel to perform a logon, logoff, set-password, or set-authorization action. The PLC wrote the operator's user number, password hash, and desired authorization level into the remaining mailbox words; the panel accepted the request, applied the change, and wrote a status word back to the PLC acknowledging success or returning an error code.

The standard function IDs in the Comfort jobmailbox were:

The engineering appeal of the jobmailbox was that the PLC - and by extension the MES connected to the PLC - was the single source of truth for "who is at the panel right now and what are they allowed to do." Operators did not have to log into the HMI at all; their RFID badge tap at the machine was sufficient to put the panel into the correct authorization state. The status bar at the top of the Comfort screen displayed the operator name from the PLC.

The jobmailbox disappeared with the Unified Comfort Panel generation. The MTP panels use a different user management model based on the WinCC Unified runtime, and the runtime no longer accepts jobmailbox-style logon requests.

3. WinCC Unified User Management Architecture

WinCC Unified (both PC Runtime and Unified Comfort Panel runtime) implements user management through the User Management Component (UMC). UMC supports:

• Local user databases stored on the runtime, configured in TIA Portal under "Runtime settings > User management."
• SIMATIC Logon integration for central user management against a Windows domain, configured under "Runtime settings > User management > Connection."
• Role-based access control (RBAC) where each user belongs to one or more groups and each group carries a numeric authorization level (0-99 in WinCC Unified, where higher numbers are typically interpreted as more privileged).
• Time-bounded credentials, certificate-based authentication, and passcode policies enforced by the runtime.

Authentication on the panel is performed by a logon dialog (the system function ShowLogonDialog) or by a configured automatic logon. Once a user is logged in, the runtime exposes the user's name, group membership, and authorization level to the rest of the system through internal properties and through the JavaScript / C / VB API.

The Unified runtime exposes a set of system functions for the logon lifecycle. The functions relevant to a PLC-driven login use case include:

Crucially, none of these functions accept a credential pair (user name, password) or a user identifier as a parameter. The runtime is designed around the assumption that credentials are presented by a human through the logon dialog or by SIMATIC Logon from a domain.

This is the root cause of the engineering gap: the API surface that would let a script write a credential into the runtime is not exposed.

4. Login and Logoff Behavior in WinCC Unified

The behavior of the logon and logoff lifecycle on WinCC Unified is documented in the Siemens Industry Online Support entry 109818319 - Login and Logoff behavior for WinCC Unified PC Runtime / SIMATIC HMI Unified Comfort Panel. The entry covers the PC Runtime, the Unified Comfort Panel, and the Unified Comfort Panel specifically. The key behavior for engineering planning purposes:

• A user is logged on for the entire Unified runtime, not per screen. The same identity persists across screen changes, pop-ups, and screen objects.
• To switch identity, the active user must explicitly log off before another user can log on. There is no fast-user-switching without logoff.
• The Logoff system function terminates the current session and returns the runtime to the unauthenticated state. All secured operations, including secured screen objects and secured scripts, immediately become inaccessible.
• Once a user is logged off, the runtime does not retain the previous identity - the next user is unrelated.
• The "automatic logoff" timer configured under User Management in the runtime settings enforces an idle timeout for the current session. When the timer expires, the runtime performs an automatic Logoff.

The implication for PLC-driven login is that even if a mechanism existed to write a user into the runtime from a tag, the runtime would still require the current user to log off first. A PLC-side script that attempted to enforce a login would have to issue Logoff, then somehow inject the next identity, then open ShowLogonDialog - and the operator would still have to type the password.

5. Documented Limitations in TIA Portal V19 and V20

As of TIA Portal V19 (released late 2023) and continuing into V20 (released mid-2024), the published WinCC Unified runtime does not expose a system function or public API for programmatic user logon. The Unified scripting system supports JavaScript and (under specific TIA Portal versions and with restrictions) C scripts, but the authentication API surface is not extended beyond the system functions listed in Section 3.

Engineering support requests submitted to Siemens on this topic have returned consistent answers: the feature is not available in V19 / V20, and engineers are pointed to the workaround of using property dynamization on the Enabled property of secured screen objects. Siemens development is publicly acknowledged to be working on a JavaScript-based mechanism that will allow logon via the script API; no published release date exists.

The TIA Portal V20 documentation portal is the canonical reference for the current state of the scripting API and is updated with every service pack.

6. Workaround 1: Enabled Property Dynamization with PLC Authorization Tags

The recommended workaround, and the one Siemens support points engineers toward, is to abandon the concept of "log in a user from the PLC" and instead implement authorization at the screen-object level. The Unified runtime supports dynamization of the Enabled property of any screen object against a tag, a script, or an expression. The expression can be a simple comparison between a PLC tag and a constant, or it can call a JavaScript function that returns a boolean.

The pattern is:

1. Define a PLC tag, for example in a data block, that holds the current operator's authorization level. The MES writes this value into the PLC when the operator badges in.
2. Define a Unified tag, mapped to the PLC tag, that exposes the authorization level to the runtime.
3. On every secured screen object, configure a dynamization on the Enabled property: Enabled = (CurrentAuthorizationLevel >= RequiredAuthorizationLevel)
4. On every secured screen object, configure a dynamization on the Visibility property if you want a hidden element to appear (for example, an "Admin" button that should only be visible to administrators).
5. Maintain a "current user identity" string tag in the PLC (for example, HmiUser.Name as a WString[32]) and map it to a Unified tag. Display this tag at the top of the screen as the "logged in user" indicator, even though the user has not been authenticated against UMC.

The dynamization expression syntax in WinCC Unified accepts comparisons, boolean operators, and JavaScript function calls. Examples:

// Enabled expression on a "Stop Machine" button
return Tags("HMI_AuthorizationLevel").Read() >= 30;

// Visibility expression on an "Admin Panel" tab
return Tags("HMI_AuthorizationLevel").Read() >= 90;

// Combined: operator must have level >= 30 AND be in the correct shift
return Tags("HMI_AuthorizationLevel").Read() >= 30 && Tags("HMI_ShiftCode").Read() == 1;

// Mapping a numeric level to a role name (used for display only)
function getRoleName(level) {
  if (level >= 90) return "Administrator";
  if (level >= 60) return "Supervisor";
  if (level >= 30) return "Operator";
  if (level >= 10) return "Trainee";
  return "Unauthenticated";
}

The drawback is that the user is not "logged in" in the audit sense. The UMC audit log will not record their actions because the actions are happening as the system default user. To preserve an audit trail, you must implement a separate logging mechanism in the PLC or in the Unified runtime that records which operator performed which action, sourced from the MES-provided identity tag.

The advantage is that this pattern is fully supported, deterministic, and works on every Unified Comfort Panel from MTP700 to MTP2200 without any firmware or runtime version dependency beyond the dynamization feature itself.

7. Workaround 2: Display-Only Authentication Mapping

A second pattern that combines well with Workaround 1 is the display-only authentication mapping. In this pattern, the PLC does not authenticate the operator against UMC, but the Unified runtime displays the operator's name and authorization level on the screen in a way that other operators and supervisors can see. This is sufficient for plants where the audit trail is owned by the MES and the HMI is used only to inform the operator of their current rights.

The MES-driven identity is broadcast to every panel on the plant floor; the panel's job is to render that identity, not to authenticate against it. The PLC acts as the broadcaster, holding the current session state and exposing it to the panels over the S7 connection.

Implementation steps:

1. Create a data block on the PLC (see Section 10 for the full layout) with the operator identity fields.
2. Map the symbols to Unified tags in the HMI configuration.
3. On every screen, place a status bar that displays OperatorName, AuthorizationLevel as a role name (look up the integer against a constant array), and ShiftCode.
4. Secure every action by Enabled dynamization as in Workaround 1.
5. Record every operator action in the MES-side audit log, not in the UMC log.

This pattern is the cleanest for plants where the MES is the single source of truth for identity. The Unified runtime never authenticates anyone, which means there is no UMC user list to maintain, no password rotation policy, and no synchronization issue between the MES and the HMI's local user database.

8. Workaround 3: Python Runtime (Unofficial, Not Supported)

Some engineers have observed that the Unified Comfort Panel runtime ships with a Python interpreter. This is correct: the MTP generation runs on an embedded Linux platform that includes Python as a system component for internal use (logging, diagnostics, update agents). The interpreter is not part of the WinCC Unified application runtime and is not documented, supported, or guaranteed to remain present in future firmware updates.

Siemens technical support has, in at least one documented case, provided a Python script that reads a credential file and calls into the runtime to perform a logon. The script depends on internal API surface that is not part of the public WinCC Unified contract. Using this approach means accepting the following risks:

• The Python interpreter can be removed or replaced in a future firmware update.
• The internal API surface can change without notice.
• The script may break across TIA Portal upgrades.
• The script will not be supported by Siemens when you file a service request.
• Security review of the script and its dependencies is the integrator's responsibility.
• Updates installed via SIMATIC Automation Tool or the panel's firmware update menu can silently break the script.

9. Workaround 4: JavaScript Runtime (Planned by Siemens R&D)

Siemens development has indicated that a JavaScript API extension to allow programmatic user logon is in the pipeline. The current Unified JavaScript API exposes:

• Tags("...").Read() and .Write() for tag access
• HMIRuntime.Trace() for logging
• HMIRuntime.UI for screen object access
• HMIRuntime.UserManagement for read-only access to the current user

The UserManagement namespace is read-only as of V19 and V20. A future API is expected to expose LogonUser(name, password) or LogonWithCertificate(cert), but the API name, signature, and release date are not published.

Engineers who want to use the JavaScript runtime to bridge the gap should:

1. Subscribe to the TIA Portal What's New documentation for each service pack.
2. Check the WinCC Unified Scripting reference manual for new UserManagement methods.
3. Test the panel firmware with the latest service pack before committing to a new project.
4. Design the project so that the future API can be slotted in with a single function call swap, by isolating the login logic in a single global script function.

The TIA Portal V20 documentation portal is the canonical reference for the current state of the scripting API. The documentation is updated with every service pack.

10. S7-1500 / S7-1515F Data Block Layout for Operator Identity

The MES-driven identity pattern requires a data block on the S7-1500 (or S7-1515F for fail-safe applications) that the MES writes to when an operator badges in. The recommended structure is:

The data block should be configured with optimized access and the "Accessible from HMI" attribute on every symbol, so the Unified runtime can poll the values through the S7 connection.

The MES writes the entire block atomically using a PUT or a single S7 function call. The IsValid flag is the last field the MES writes; the HMI-side script watches this flag and the SessionId counter to detect a logon event.

A typical HMI-side JavaScript handler:

// Global script function triggered on SessionId change
function onSessionChange() {
  var isValid = Tags("DB_Operator.IsValid").Read();
  var sessionId = Tags("DB_Operator.SessionId").Read();
  var name = Tags("DB_Operator.OperatorName").Read();
  var level = Tags("DB_Operator.AuthorizationLevel").Read();
  var shift = Tags("DB_Operator.ShiftCode").Read();
  var ts = Tags("DB_Operator.LogonTimestamp").Read();

  if (isValid && sessionId !== lastSeenSessionId) {
    HMIRuntime.Trace("Operator logon: " + name + " level " + level + " shift " + shift);
    // Update header bar text fields
    HMIRuntime.UI.Screen.Items("HeaderOperatorName").Text = name;
    HMIRuntime.UI.Screen.Items("HeaderRoleName").Text = getRoleName(level);
    lastSeenSessionId = sessionId;
  } else if (!isValid) {
    HMIRuntime.UI.Screen.Items("HeaderOperatorName").Text = "No operator";
    HMIRuntime.UI.Screen.Items("HeaderRoleName").Text = "Unauthenticated";
    lastSeenSessionId = 0;
  }
}

For fail-safe applications (S7-1515F and the associated F-CPU), the operator identity data block should be in the standard (non-F) part of the PLC, because the HMI cannot consume F-tag data directly. The MES-to-PLC write is also a standard write, not a safety-relevant operation.

11. MES-Synchronized User Database Architecture

For plants that are standardizing on the MES-as-source-of-truth pattern, the recommended architecture is summarized in the table below and in the data flow diagram that follows.

The data flow is:

1. Operator badges in at a card reader. The reader outputs the badge serial to the PLC over the fieldbus (PROFINET, for example).
2. The MES connection to the PLC (typically a PUT instruction from the MES server, or a read on a heartbeat tag that the MES polls) sees the badge event, looks up the badge ID, checks certifications, determines the authorization level, and writes a "SetOperator" record to the PLC's operator data block.
3. The PLC stores the operator identity in the data block and exposes it to the HMI through the existing S7 connection.
4. The HMI displays the operator name and enforces authorization through Enabled dynamization against the tag values.
5. Operator performs actions on the HMI; the actions are written to the PLC with the operator identity attached.
6. The PLC forwards the action log to the MES for long-term archival. The MES-side audit log is the legal record of the operator's actions.

This architecture scales to any number of panels, supports a single user list maintained in the MES, and survives the operator logging in on multiple panels simultaneously. The Unified runtime never has to authenticate anyone, which means the migration from Comfort to Unified is significantly simpler.

12. Migration Strategy from Comfort to Unified Comfort Panels

The migration from a Comfort Panel deployment to a Unified Comfort Panel deployment is a multi-step process. The key engineering decisions are:

The recommended migration sequence is:

1. Stand up the MES-driven identity data block. Add the operator data block to the PLC and the MES write logic. This does not require a panel change. The MES starts writing the operator identity to the PLC even if the existing Comfort panel ignores it.
2. Deploy the Unified Comfort Panel in parallel. Configure the Unified panel with the new dynamization-based authorization. Run it in parallel with the old Comfort Panel for a defined burn-in period (typically 4 to 12 weeks for a regulated environment).
3. Decommission the Comfort panels. Once the Unified deployment is stable and the operators are trained, decommission the Comfort panels.
4. Update SOPs. Update the standard operating procedures to reflect the new "badge in at the machine, the panel reflects the operator" workflow. Train every operator and supervisor on the change.

For global fleets running mixed TIA Portal versions, the data block structure is identical across V17, V18, V19, and V20 projects because the tag definitions are PLC-side. The Unified panels on V17 and V18 will not benefit from any future JavaScript logon API; the dynamization pattern is the only path for them.

13. Verification, Commissioning, and Audit Trail

Verification of the MES-driven identity pattern requires the following test cases:

1. Valid operator logon. Operator badges in with valid credentials. The PLC's OperatorName tag is updated within one MES write cycle (typically under 1 second). The Unified panel's status bar reflects the operator name.
2. Logoff / clear. Operator badges out. The PLC's OperatorName tag is cleared. The Unified panel's status bar reverts to the "no operator" indicator. All previously-enabled secured objects are disabled.
3. Insufficient authorization. Operator with insufficient authorization attempts to use a secured object. The Enabled dynamization evaluates to false and the object is unresponsive.
4. Network disconnect. Network is disconnected between the MES and the PLC. The PLC retains the last-known operator state. The Unified panel continues to display the last-known operator. Secured objects remain in the last-known authorization state. (This is an explicit design choice; some plants prefer to fail-secure and clear the authorization on disconnect.)
5. Multi-panel reflection. Multiple panels reflect the same operator. The MES broadcasts the operator identity to every PLC, every Unified panel reflects the identity.
6. Session counter. The PLC's SessionId increments only when the operator actually changes, not on every MES write of the same identity.
7. Stale data detection. If the MES has not written the operator block within the configured staleness threshold, the panel displays a "stale data" warning and the operator can re-badge to refresh.

Commissioning checklist:

• MES write cycle time documented and verified at the worst-case network load
• PLC data block retention on PLC restart defined and tested (the operator identity should be cleared on restart, not retained)
• Unified panel tag refresh rate set to match the MES write cycle to avoid stale displays
• Enabled dynamization expressions unit-tested for off-by-one errors at the authorization boundary (operator has level 29, object requires level 30)
• Status bar visibility tested for the empty-state case
• Audit log written and archived before the next shift
• Fail-safe behavior on MES disconnect tested and documented

The verification of the logon / logoff lifecycle itself should follow the procedure documented in Siemens Support entry 109818319 for the specific runtime version in use.