1. 课程导入与工程认知

在流程工业中，报警系统本应是操作员判断装置异常、及时干预的最后一道防线。然而当大量报警在短时间内集中涌现，操作员来不及逐条确认、判断与处置时，报警系统反而从"保护屏障"变成了"干扰源"。这种现象就是报警风暴（Alarm Flood）。AVEVA（原 Wonderware）System Platform、InTouch 及 AVEVA Historian 等产品线中，报警子系统承担着报警产生、优先级判定、状态管理、历史归档与客户端呈现的完整链路，因此报警风暴的治理必须放在这条完整链路上理解，而不能只盯着操作画面上的报警条。

一、报警风暴的工程定义与量化判据

报警风暴并非"报警多"这么模糊的描述，工程上通常用单位时间报警率来界定。EEMUA 191 与 ISA-18.2 给出的参考阈值是：稳态运行时，每 10 分钟每操作员超过 10 条报警即进入"可接受上限"；若 10 分钟内超过 100 条，则属于典型的报警风暴区间。换算成报警率，即稳态目标应控制在 ≤1 条/分钟/操作员，峰值不应持续超过 10 条/分钟/操作员。

需要强调的是，报警风暴的判定必须绑定"操作员"和"时间窗"两个维度。同一套装置在 DCS 上产生 300 条报警，如果分散在 8 小时内由 3 名操作员分担，并不构成风暴；但若集中在 5 分钟内涌向同一操作员，即使总量只有 80 条，也已经是风暴。因此治理工作的第一步不是"删报警"，而是建立可量化的报警率基线。

二、典型场景：报警风暴从哪里来

报警风暴的成因通常不是单一报警点，而是"一个根因 + 大量衍生报警"的连锁反应。常见场景包括：

• 工艺波动引发的连锁报警：进料温度偏高导致反应器压力上升，进而触发压力高、温度高、液位波动、下游流量低等一串报警，根因只有一个，衍生报警却有几十条。
• 仪表故障与信号抖动：变送器接触不良或信号噪声导致 PV 在报警限附近反复穿越，产生大量"抖动报警"（chattering alarm）。
• 报警限设置不合理：报警限与正常操作区间过近，正常调节就会触发报警，属于"设计性风暴"。
• 停车/开车等工况切换：非正常工况下大量联锁与报警同时动作，属于"工况性风暴"。
• 系统层面的重复与冗余报警：同一测点在不同层级、不同画面、不同子系统重复配置，一次异常被放大数倍。

在 AVEVA 体系中，这些报警最终都会汇聚到 Alarm Provider（如 $System、PLC 驱动、InTouch 报警组）并写入 Historian。因此排查时必须沿着"现场信号 → 驱动/PLC → Alarm Provider → 报警优先级 → 客户端呈现 → Historian 归档"这条链路逐段定位，而不是只在画面上做屏蔽。

三、治理目标：从"减少报警"到"恢复报警有效性"

报警风暴治理的目标不是把报警数量压到零，而是让每一条报警都可被操作员看见、理解并采取行动。具体可拆成四个可衡量的目标：

1. 报警率达标：稳态 ≤1 条/分钟/操作员，峰值 ≤10 条/分钟/操作员。
2. 优先级分布合理：高优先级（如 Critical/High）占比通常控制在 5%～15%，避免"全是高优先级等于没有优先级"。
3. 抖动报警清零：同一报警点在 1 分钟内反复出现 3 次以上即视为抖动，需通过死区、延时或滤波消除。
4. 根因可追溯：每条报警都能对应到明确的工艺或设备原因，而不是"系统噪声"。

这四条目标对应到 AVEVA 工程中，分别落在报警限与死区配置、优先级字段、Alarm Provider 的报警属性、以及 Historian 的报警事件查询与统计上。也就是说，治理不是一次性的"调参"，而是一个建立基线 → 根因分析 → 优化设计 → 验证固化 → 持续迭代的闭环工程。

四、优化工程的整体框架

把上述闭环落到 AVEVA 项目上，可以组织成五个层次的工作：

需要特别提醒的是，抑制（Suppression）和屏蔽（Disable）不是同一件事。抑制是在特定工况下暂时不向操作员呈现报警，但报警仍被记录；屏蔽则是彻底关闭报警产生。治理中应优先使用抑制、延时和死区，谨慎使用屏蔽，并且所有变更都必须可追溯、可回退。