4. 报警优先级与分类标准

报警优先级不是“重要/不重要”的主观排序，而是一套把后果严重度与允许响应时间结合起来的工程判据。ISA 18.2 与 EEMUA 191 给出的核心思路一致：先按后果定“严重度”，再按操作员可用时间定“紧迫度”，两者交叉后落到有限的优先级档位上。AVEVA（System Platform / InTouch / Historian 体系）本身不替你决定优先级，它提供的是承载这套判据的字段、属性和运行时行为，因此工程上真正要做的是“标准判据 → 属性字段 → 运行时表现”的三段映射。

一、标准给出的判据骨架

ISA 18.2 推荐把报警按后果分为若干严重度等级，典型做法是：无后果（No Consequence）、轻微（Minor）、较大（Major）、严重（Critical）、灾难性（Catastrophic）。EEMUA 191 则更强调“报警必须可行动”，并给出以响应时间为核心的优先级划分：紧急（Emergency，秒级）、高（High，分钟级）、中（Medium，十分钟级）、低（Low，小时级或班次级）。两者并不冲突：ISA 18.2 管“后果有多重”，EEMUA 191 管“还剩多少时间”，工程上通常把二者做成一张二维矩阵，再压缩成 3～4 个可落地的优先级。

需要特别强调一个常见误区：优先级不等于报警类型。报警类型（如高高限、偏差、故障、离散状态）描述“发生了什么”，优先级描述“需要多快响应”。在 AVEVA 中这两者应分别用不同属性承载，不能混用同一个字段。

二、从标准到 AVEVA 属性的映射

在 AVEVA System Platform 的 Galaxy 中，报警通常挂在模板（Template）的 Attribute 上，通过 Alarm 扩展属性配置。建议建立如下映射关系：

• 严重度 → 自定义属性 Severity（枚举 0–4），对应 ISA 18.2 五级；
• 允许响应时间 → 自定义属性 ResponseTime_s（数值，秒），对应 EEMUA 191 时间档；
• 最终优先级 → 报警扩展属性 Priority（1–4，1 最高），由矩阵计算得出；
• 报警类别 → AlarmType 或 Category，用于过滤与统计；
• 是否可行动 → 布尔属性 Actionable，为假时应抑制或降级。

这样做的价值在于：优先级可追溯、可批量重算，而不是在每条报警上手工填一个数字。当工艺变更导致响应时间变化时，只需改 ResponseTime_s，优先级由脚本或计算属性自动刷新。

三、优先级矩阵与配置示例

下面给出一个可直接参考的二维判据矩阵（示例参数，需按项目实际后果分析调整）。行是 ISA 18.2 严重度，列是 EEMUA 191 响应时间档，交叉格给出 AVEVA 中的 Priority 值：

在 AVEVA 中落地时，可在模板上写一段计算脚本，把矩阵固化为逻辑。例如在 Priority 属性的 OnScan 或数据变更脚本中：

' 示例：由 Severity 与 ResponseTime_s 计算 Priority
Dim sev As Integer
Dim rt As Integer
Dim pri As Integer

sev = Me.Severity        ' 0=None,1=Minor,2=Major,3=Critical,4=Catastrophic
rt  = Me.ResponseTime_s  ' 允许响应时间，秒

If sev = 0 Then
    pri = 4              ' 无后果，最低
ElseIf sev >= 3 And rt <= 60 Then
    pri = 1              ' 严重/灾难性且一分钟内
ElseIf sev >= 2 And rt <= 600 Then
    pri = 2
ElseIf sev >= 1 And rt <= 600 Then
    pri = 3
Else
    pri = 4
End If

Me.Priority = pri

这段逻辑只是把矩阵翻译成代码，实际项目中应把它放在模板层，让所有实例继承，避免逐点配置。配置完成后，用 Priority 驱动 InTouch 报警控件的颜色、声音与排序，用 Category 驱动过滤，用 Actionable 驱动抑制。

四、运行时表现与验证

优先级配置是否生效，要看运行时行为而不是看属性值。验证要点包括：Priority=1 的报警是否置顶、是否触发独立声音、是否要求确认；Priority=4 是否只进历史不弹窗；被抑制的报警是否在 Historian 中留痕。AVEVA Historian 中可按 Priority 与 Category 做聚合查询，统计各优先级报警次数与确认时长，用来反查矩阵是否合理——如果 Priority=1 的报警每小时出现几十条，说明判据过松，需要收紧严重度或响应时间。

五、配置要点与常见坑

第一，优先级字段要唯一。AVEVA 中若同时存在系统内置 Priority 与自定义 Priority，运行时会以其中一个为准，容易造成“界面显示 1、实际按 3 处理”的错位。建议统一使用报警扩展属性中的 Priority，并在模板层锁定。

第二，响应时间要写清参照起点。EEMUA 191 的响应时间是从报警产生到操作员完成有效动作的时间，不是从报警产生到点击确认的时间。配置 ResponseTime_s 时应在属性描述中写明定义，避免不同工程师按不同口径填写。

第三，抑制要有条件、有留痕。无后果报警不应简单删除，而应通过 Actionable=False 或条件抑制处理，并在 Historian 中保留记录，便于后续统计报警率。ISA 18.2 建议的报警率目标是每操作员每 10 分钟不超过 1 条，优先级配置完成后应据此复核。

把标准判据、属性字段和运行时行为三者对齐后，优先级才真正成为可执行、可审计、可优化的工程参数，而不是贴在报警上的一串数字。