4. 基于用户组的权限设计
在WinCC的权限体系中，用户组不是简单的“用户集合”，而是一套可继承、可覆盖、可冲突裁决的权限计算模型。理解这套模型的关键在于：权限最终生效值不是由某一个位置单独决定，而是由“组继承链”和“个体覆盖”共同计算得出。如果只把用户组当作分类标签，就会在组权限与个体权限冲突时无法判断谁说了算，导致运行时按钮该灰的不灰、该锁的不锁。
一、权限继承与覆盖的基本规则
WinCC的权限分配通常落在“对象—权限等级—用户/用户组”这条链上。对象可以是按钮、输入域、画面窗口、趋势控件等；权限等级是对象上声明的“需要什么级别才能操作”；用户和用户组则持有“被授予了哪些级别”。当用户登录后，系统按以下顺序计算：
- 先取用户所属用户组的权限集合，多个组时取并集，即“只要有一个组授予了某权限，用户就拥有该权限”。
- 再应用用户个体权限。个体权限对组权限有两种作用：追加授予或显式拒绝。
- 冲突裁决：当组授予而个体拒绝时，个体拒绝优先；当组未授予而个体授予时，个体授予生效。也就是说，拒绝的优先级高于授予。
这条规则决定了角色化权限模型的设计方向：组负责“批量给能力”，个体负责“例外收能力”。如果反过来，用个体去补组没给的能力，模型会迅速碎片化，后期无法维护。
核心结论：组权限是基线，个体权限是修正项；修正项中“拒绝”永远压过“授予”。设计时应尽量让个体只做拒绝，不做额外授予。
二、角色化权限模型：操作员、工程师、管理员
把权限等级按“能力递增”排列，是角色化设计的第一步。WinCC中常见的权限等级可抽象为：
| 等级 | 典型能力 | 对应角色 |
|---|---|---|
| L1 观察 | 查看画面、趋势、报警列表 | 操作员 |
| L2 操作 | 启停设备、修改设定值、确认报警 | 操作员 |
| L3 工程 | 修改参数、下载配方、切换控制模式 | 工程师 |
| L4 管理 | 用户管理、权限分配、审计导出 | 管理员 |
基于此，建立三个用户组：
- Group_Operator（操作员组）：授予L1、L2。该组用户能看、能操作，但不能改工程参数。
- Group_Engineer（工程师组）：授予L1、L2、L3。工程师既能操作也能改参数。
- Group_Admin（管理员组）：授予L1～L4。管理员拥有全部权限，并负责用户与审计。
注意：这里采用“能力递增”的授予方式，即高等级组包含低等级组的全部权限。这样做的目的是让“组继承”语义清晰——工程师天然具备操作员能力，不需要额外配置。若采用互斥式授予，工程师登录后反而不能操作设备，必须再挂一个操作员组，模型会变复杂。
三、组权限与个体权限冲突的处理
实际工程中，冲突主要出现在三类场景，下面逐一给出处理方式。
场景一：工程师临时被禁止操作某台设备。某工程师属于Group_Engineer，拥有L2操作权限，但因其正在对该设备做参数调试，需要临时禁止其启停操作。此时不应把他移出工程师组，而应在该用户的个体权限中，对“设备启停”对应的权限点显式设为“拒绝”。由于拒绝优先，即使组授予了L2，该用户也无法操作该设备。调试结束后删除该条个体拒绝即可恢复。
场景二：操作员需要临时获得一个工程师权限。例如夜班操作员需要修改一个配方参数。正确做法不是给个体加L3，而是临时将其加入Group_Engineer，或建立一个“临时工程师”组并设置有效期。原因是：个体授予会绕过组的统一管理，审计时难以追溯“为什么这个操作员有L3”。如果确实必须用个体授予，应在审计记录中标注授权原因和期限。
场景三：同一用户属于多个组，权限出现交叉。例如某用户既是Group_Operator又是Group_Engineer。按并集规则，他拥有L1、L2、L3。此时若个体拒绝L3，则最终只有L1、L2。若个体拒绝L2但组授予L2，最终仍无L2。判断口诀是：先并集、后个体、拒绝赢。
四、在WinCC中落地角色化权限模型
落地时，建议按以下顺序操作，避免边配边改导致权限混乱。
第一步：定义权限等级与权限点。在用户管理器中建立L1～L4四个等级，并为每个等级绑定具体权限点。权限点命名要能对应到对象，例如“画面_主画面_查看”“设备_泵P01_启停”“参数_配方_修改”“系统_用户管理”。不要只建等级不建权限点，否则对象上无法精确声明需要什么。
第二步：建立三个用户组并授予等级。Group_Operator授予L1、L2；Group_Engineer授予L1、L2、L3；Group_Admin授予L1～L4。授予时使用“组—等级”绑定，不要逐个用户授予。
第三步：在对象上声明所需权限。例如主画面“查看”按钮声明需要L1；泵P01“启动”按钮声明需要L2；配方修改输入域声明需要L3；用户管理画面声明需要L4。对象声明的是“门槛”，用户持有的是“钥匙”，两者匹配才可操作。
第四步：处理个体例外。只对确实需要的用户添加个体权限，且优先使用“拒绝”。添加时记录三要素：用户、权限点、原因与期限。例如“张工、设备_泵P01_启停、调试期间禁止操作、2025-06-30前有效”。
第五步：验证冲突裁决。用三个测试账号分别登录：操作员账号应看不到L3/L4对象；工程师账号应能操作L2、修改L3，但被个体拒绝的泵P01启停按钮应灰显；管理员账号应能进入用户管理。若工程师账号仍能启停P01，说明个体拒绝未生效或对象未声明L2，需检查权限点绑定。
常见错误：把“拒绝”配成了“不授予”。在WinCC中，不授予只是“没有”，而拒绝是“明确禁止”。当用户同时属于多个组时，不授予会被其他组的授予覆盖，只有显式拒绝才能压住。因此处理冲突必须用拒绝，不能用“从组里移除”代替。
五、审计视角下的权限模型检查
权限模型设计完成后，应从审计角度做一次反向检查：每个用户当前生效的权限集合是什么？这些权限来自哪个组、哪条个体规则？是否存在“个体授予”绕过了组管理？是否存在长期未清理的临时拒绝？建议在用户管理器中导出用户—组—个体权限清单，逐条核对。对于操作员组，重点检查是否误授了L3；对于工程师组，重点检查个体拒绝是否过期未删；对于管理员组，重点检查人数是否过多。
一个可维护的角色化权限模型，最终应满足三个特征：组结构稳定、个体例外极少、冲突裁决可预测。做到这三点，后续新增用户只需挂组，新增对象只需声明等级，权限管理就不会随项目规模增长而失控。