1. WinCC权限与审计工程全景

在SCADA系统中，操作员能做什么、不能做什么，以及做过什么、何时做的，是两件必须被工程化解决的问题。前者由用户权限管理回答，后者由操作审计追踪回答。WinCC作为西门子过程可视化平台，把这两件事分别落在用户管理器（User Administrator）和审计追踪（Audit Trail）两个核心组件上，并通过全局脚本、报警记录和归档系统把它们串联起来。理解这套全景，是后续所有配置工作的前提。

一、权限与审计在SCADA中的定位

SCADA系统的本质是"人通过HMI对现场设备施加控制"。这个过程中存在三类风险：越权操作（低权限人员执行高权限动作）、误操作（有权限但操作错误）、事后无法追溯（出了问题查不到是谁在什么时间改了什么）。权限管理解决前两类中的"准入"问题，审计追踪解决第三类问题。二者不是可选项，而是等保2.0、IEC 62443以及GMP等合规场景下的强制要求。

在WinCC中，权限与审计的边界可以这样界定：权限决定"能不能点"，作用于画面对象的"授权"属性；审计决定"点了之后留下什么"，作用于操作事件、报警确认、变量写入等动作的记录。二者共享同一个用户身份体系——没有登录用户，权限无从判断，审计也无从归属。

二、WinCC内置用户管理的总体架构

WinCC的用户管理采用"用户组—用户—权限等级"三层结构。权限等级是0到999的整数编号，编号越大权限越高，但WinCC并不自动比较大小，而是由画面对象显式声明"需要哪个编号的授权"。这意味着权限编号本身没有语义，语义由工程约定赋予。

一个典型的工程约定如下表所示（示例参数，非实测结果）：

用户管理器中的"授权"是逐项勾选的，一个用户可以同时拥有多个授权编号。画面对象在"属性→安全"中设置"授权"值，运行时WinCC将当前登录用户的授权集合与对象要求的授权做匹配，匹配失败则对象变为灰色且不可点击。这就是权限控制的执行机制。

三、审计追踪的总体架构

WinCC的审计追踪不是独立数据库，而是建立在报警记录（Alarm Logging）和变量记录（Tag Logging）之上的结构化记录层。其工作链路是：操作事件发生 → 触发审计消息 → 写入报警归档 → 通过WinCC Audit Viewer或报表导出查看。

需要审计的典型事件包括：用户登录/注销、权限变更、变量写入（尤其是设定值）、报警确认、配方下载、画面切换（可选）。每条审计记录至少包含：时间戳、用户名、事件类型、对象名称、旧值、新值。WinCC Audit Trail默认使用SQL Server归档，归档分段大小和备份策略需要在工程初期规划，否则后期数据量增长会导致查询缓慢。

四、权限与审计的协同关系

下图展示了WinCC中用户身份、权限判断、操作执行与审计记录之间的完整信号与数据流关系。可以看到，用户登录后身份信息同时流向权限判断和审计记录两条路径，这是二者协同的基础。

五、工程边界与常见误区

明确边界可以避免后期返工。WinCC内置用户管理不提供集中式域认证（需配合SIMATIC Logon）、不提供细粒度的对象级权限（只有授权编号匹配）、不提供审计记录的实时防篡改加密（依赖SQL Server权限和归档完整性）。这些边界决定了：如果项目要求域账号登录，必须引入SIMATIC Logon；如果要求"同一画面不同按钮不同权限"，需要用授权编号组合实现；如果要求审计记录具备法律效力，需要额外规划归档签名和备份策略。

六、工程实施的基本顺序

建议按以下顺序推进，避免反复调整：

1. 规划授权编号表：与工艺、安全、合规三方确认角色和权限边界，形成编号—角色—对象对照表。
2. 在用户管理器中建立用户组和用户：按角色建组，用户归组，逐项勾选授权。
3. 在画面对象上设置授权属性：按钮、I/O域、阀门等逐一设置，建议用面板类型（Faceplate）统一管理。
4. 配置审计追踪：在报警记录中启用Audit Trail，选择需要审计的事件类型，设置归档分段和备份路径。
5. 联调验证：用不同权限账号登录，验证灰显/可操作状态；执行一次变量写入，在Audit Viewer中确认记录包含用户名、时间、旧值、新值。

以一个具体示例说明验证过程：假设对象"反应釜温度设定值"要求授权500，当前登录用户为"engineer01"（授权500、200）。操作员将其从80.0℃改为85.0℃并确认。此时Audit Viewer中应出现一条记录：时间2025-03-15 14:22:07，用户engineer01，事件"变量写入"，对象"Reactor_Temp_SP"，旧值80.0，新值85.0。若记录中缺少用户名或旧值，说明审计配置不完整，需要检查报警记录中该变量的"审计"属性是否勾选。