Segregating Operator Control Across WinCC OS Clients: Area Authorization and Local Operator Permission

Segregating Operator Control Across WinCC OS Clients: Area Authorization and Local Operator Permission

Segregating control so that an OS Client monitors all plant areas but controls only specific assigned areas requires coordinating WinCC User Administrator with Picture Tree Area Authorizations or APL Local Operator Permission (OpPerm). If activating control authorizations causes an OS Client to lose control across all WinCC pages, the user group was likely denied basic Level 5 ('Process controlling') global rights, or the Picture Tree hierarchy was not compiled to propagate technological area nodes. To resolve this, configure Area-specific authorization levels in User Administrator, ensure the plant hierarchy assigns pictures to areas correctly, and utilize APL Local Operator Authorization (Feature bit 24 or station name filters) to enforce client-specific physical boundaries.

Table of Contents

User Identity Security vs Station-Specific Physical Control Segregation

In multi-client SIMATIC PCS 7 distributed control systems, engineering requirements frequently mandate strict geographic control segregation. For example, Client 1 located in the Boiler House and Client 2 located in the Water Treatment Plant must both have complete plant-wide monitoring visibility, but operators seated at Client 1 must be strictly prohibited from starting or stopping equipment in Water Treatment, and vice versa.

Achieving this requires understanding the critical distinction between two security layers in PCS 7:
1. User Identity Security (Who is logged in?): Managed via WinCC User Administrator or SIMATIC Logon. Permissions follow the operator's user account regardless of which PC they log into.
2. Station-Specific Security (Where is the client physically located?): Managed via APL Local Operator Permission (OpPerm), @local::@LocalMachineName filters, or dedicated client project area assignments. This ensures that physical hardware location dictates operational authority.

WinCC User Administrator Architecture: General vs Area Authorizations

In WinCC Explorer, the User Administrator defines user groups and individual user authorizations:

  • Standard Authorization Levels: Standard levels include Level 1 (User administration), Level 5 (Process controlling), and Level 6 (Higher process controlling). Standard Level 5 grants global permission to manipulate standard APL faceplate setpoints, start/stop buttons, and manual/auto modes.
  • Technological Area Authorizations: When the Plant Hierarchy is compiled in SIMATIC Manager with OS Area options enabled, the Picture Tree Manager creates technological areas (e.g., Area_Boiler, Area_WaterTreatment). In User Administrator, each area appears as a discrete column or branch.
  • Authorization Matrix: To restrict an operator group to monitoring all areas while controlling only one area, the group must possess Level 5 authorization specifically enabled for Area_Boiler, while Area_WaterTreatment is assigned Level 4 (Monitoring only) or left unchecked.

Why OS Clients Experience Total Control Lockout After Permission Changes

When system integrators attempt to configure area permissions, a common failure mode is that clients abruptly lose the ability to control all WinCC pages—including their own designated unit. This total lockout stems from three common configuration pitfalls:

  1. Revoking Base Level 5 Globally: If an engineer unchecks Level 5 from the user's standard authorization list while attempting to grant area-specific rights, standard WinCC graphic objects and APL faceplates fail the global authorization check before even evaluating the area token.
  2. Missing Picture Tree Recompilation: If areas were modified in SIMATIC Manager but the OS was not recompiled (or Picture Tree Manager was not recalculated), the runtime engine cannot map the active screen name to an area token, defaulting to total lock.
  3. Standard Faceplate Header Inheritance: APL faceplates inherit their area permissions dynamically from the block's OS_Area attribute in the CFC chart. If the CFC chart container resides outside the designated Plant Hierarchy area folder, the block defaults to @NoArea, which is locked for all area-restricted operators.

Implementing Station-Specific Restrictions via APL Local Operator Permission

When the requirement is not merely user-dependent, but strictly hardware-station-dependent (i.e. even if a supervisor logs into Client 2, they cannot operate Boiler 1 valves from that desk), the APL Local Operator Permission mechanism must be implemented:

  • Feature Bit 24 (Enable local operator permission): In the APL block (e.g., MotL, VlvL, PIDConL), set Feature.Bit24 = 1.
  • OpPerm Parameter: The OpPerm block input defines a 32-bit permission mask controlling which operator actions are permissible from non-local stations.
  • Client Station Binding: In the WinCC OS Client project, client-specific scripts evaluate the system tag @local::@LocalMachineName against an authorized station list. If the active machine name does not match the designated control station for that technological area, the faceplate buttons render with a lock icon and operator input is blocked at runtime.

Step-by-Step Procedure to Configure Multi-Client Area Segregation

Follow this procedure to establish robust multi-client area segregation without lockout:

  1. Structure Plant Hierarchy: In SIMATIC Manager Component View, organize CFC charts into distinct technological hierarchy folders representing physical plant areas (e.g., Unit_A, Unit_B). Ensure each folder has the property 'Area' selected.
  2. Compile OS with Picture Tree: Execute an OS Compile with the option Picture Tree selected to update the OS area database.
  3. Configure User Administrator on OS Server:
    - Create user group Operators_Unit_A.
    - Assign Authorization Level 1001 (Monitoring) across all plant areas.
    - Assign Authorization Level 5 (Process controlling) and Level 6 (Higher process controlling) only under the column for Unit_A.
    - Repeat for Operators_Unit_B, granting Level 5/6 only to Unit_B.
  4. Configure Local Operator Authorization in CFC (if station-specific control is required):
    - In the target CM blocks, set Feature.Bit24 = 1.
    - Connect station-based interlocking or configure the OS faceplate client station filter.
  5. Download OS Server and Clients: Download server changes and client projects to activate the updated security descriptors.

Area Authorization and Station Control Assignment Matrix

The following matrix outlines the required authorization assignments across plant areas and physical client consoles:

Console / User GroupAssigned Technological AreaMonitoring PermissionProcess Controlling (Level 5)APL Local OpPerm ActiveClient 1 / Operators_ABoiler Unit (Area A)Granted (All Areas)Granted (Area A Only)Enforced via Station Name AClient 2 / Operators_BWater Treatment (Area B)Granted (All Areas)Granted (Area B Only)Enforced via Station Name BClient 3 / Shift_SuperPlant-Wide SupervisoryGranted (All Areas)Granted (All Areas)Bypass filter authorizedWeb Client / Read-OnlyRemote Web SessionGranted (All Areas)Denied (Read-Only)Blocked at Web Gateway

Verification

Verify area control segregation in WinCC Runtime through the following tests:

  1. Log into Client 1 with an operator account belonging to Operators_Unit_A.
  2. Open a graphic screen belonging to Unit_A. Click a valve icon to open its faceplate. Verify that Manual/Auto buttons, setpoint fields, and open/close commands are fully interactive.
  3. While still on Client 1, navigate to a graphic screen belonging to Unit_B. Verify that all process trends, alarms, and analog values update live (monitoring active).
  4. Click a pump icon in Unit_B. Verify that the faceplate opens, but all operational buttons display the padlock symbol or remain greyed out, preventing any control actions.
  5. Log into Client 2 with the same account or Operators_Unit_B and verify reciprocal operational authority.

Limitations and Operational Precautions

Adhere to the following operational precautions:

  • Emergency Shutdown Override: Never rely solely on WinCC User Administrator or software client segregation for personnel or equipment safety; hardwired emergency stop pushbuttons must always be provided independent of HMI clients.
  • User Group Inheritance: In WinCC User Administrator, avoid assigning individual users conflicting permissions across multiple nested groups; always verify cumulative group rights.
  • Server OS User Administrator Master: In redundant OS server environments, always configure User Administrator on the Master ES or primary server; never modify user databases locally on OS Clients, as runtime synchronization will overwrite local changes.

Engineer FAQ

Can an operator acknowledge alarms in an area where they do not have process control permission?

Alarm acknowledgment requires Authorization Level 4 (Alarm acknowledgment). In User Administrator, you can configure whether an operator group has alarm acknowledgment rights plant-wide or restricted strictly to their assigned technological area. If Level 4 is revoked for Area B, the operator can see the alarms in the banner but cannot silence or acknowledge them.

Why do faceplates show a padlock icon on an OS Client even when logged in as an administrator?

A padlock icon on an APL faceplate indicates that either: (1) The active user lacks the required authorization level for that technological area; (2) APL Local Operator Permission (Feature.Bit24) is active and the client station name does not match the authorized station list; or (3) The block is in an external forced/interlocked state (e.g., Intlock, Protect, or LocalAct is asserted).

Do I need separate WinCC user accounts if I want physical PC desks to dictate control rights?

No. If you utilize APL Local Operator Permission (Feature Bit 24) combined with @local::@LocalMachineName evaluation, the physical PC identity dictates whether control is granted, allowing generic shift operator accounts to be used seamlessly across different control room desks.

Technical References

Related Articles

Related Tags

  • WinCC User Administrator
  • Area Authorizations
  • OS Client Segregation
  • APL OpPerm
  • Local Operator Permission
  • Plant Hierarchy Areas
6 respuestas