3. 报警优先级与分类设计
报警优先级不是“重要程度”的主观排序，而是对报警触发后可能造成的后果严重度与允许响应时间的量化表达。DeltaV 的报警系统把优先级（Priority）与类别（Category）分开处理：优先级决定报警在报警横幅、报警列表中的排序与颜色，类别决定报警被路由到哪个操作员、是否参与抑制、是否记录到哪类报表。两者必须协同设计，否则会出现“高优先级报警被淹没在低优先级报警中”或“关键报警没有送到正确的操作员画面”这两类典型问题。
一、基于风险与后果的优先级矩阵
优先级矩阵的横轴是后果严重度，纵轴是允许响应时间（也可反过来，但全文必须保持一致）。本节采用“横轴=后果严重度，纵轴=允许响应时间”的约定：越靠右后果越严重，越靠上允许响应时间越短。矩阵的每个交叉格给出一个优先级建议值。DeltaV 常用 1～4 级优先级，其中 1 级最高、4 级最低（部分项目使用 1 级最高、5 级最低，配置前必须确认项目约定）。
后果严重度可按人员安全、环境影响、设备损坏、产品质量、产量损失五个维度取最严重者。允许响应时间按操作员从发现到完成有效干预所需时间估算，通常分为 <1 min、1～5 min、5～30 min、>30 min 四档。一个可参考的矩阵如下（示例参数，需按装置实际风险分析结果调整）：
| 允许响应时间 \ 后果严重度 | 轻微 | 较大 | 严重 | 灾难 |
|---|---|---|---|---|
| <1 min | 2 | 1 | 1 | 1 |
| 1～5 min | 3 | 2 | 1 | 1 |
| 5～30 min | 4 | 3 | 2 | 1 |
| >30 min | 4 | 4 | 3 | 2 |
矩阵的作用是让不同工程师对同一报警给出接近的优先级，而不是让每个人凭经验拍板。实际项目中，矩阵应由工艺、安全、仪表、操作四方共同评审，评审记录要保留，作为后续报警变更的依据。
二、报警类别定义
类别是报警的“归属标签”，用于把报警按来源、功能或处理方式分组。常见的类别划分方式有三种：按工艺单元（如反应器、精馏塔、罐区）、按报警功能（如安全联锁、工艺偏离、设备状态、通信故障）、按处理责任（如内操、外操、电气、仪表）。一个报警可以同时属于多个类别，但主类别只能有一个，主类别决定默认路由。
类别定义要落到具体字段上，至少包括：类别名称、类别代码、默认优先级、默认路由操作站、是否参与报警抑制、是否记录到报警统计报表。例如“反应器-安全”类别，默认优先级 1，路由到反应器操作站，不参与抑制，记录到安全报警报表；“公用工程-状态”类别，默认优先级 4，路由到公用工程操作站，参与抑制，记录到状态报警报表。
三、DeltaV 中优先级与类别的配置方法
在 DeltaV 中，报警优先级和类别通过报警属性（Alarm Properties）配置。以一台反应器温度变送器 TT-101 的高报警为例，配置路径为：Control Studio 或 DeltaV Explorer 中找到该模块的报警块（如 PID 块的 HI_ALM），打开属性页，在 Priority 字段填入 1～4 的整数，在 Category 字段选择已定义的类别代码。若使用 Alarm Banner 或 Alarm List，优先级决定显示颜色和排序，类别决定过滤条件。
批量配置时，推荐使用 DeltaV 的报警属性导出/导入功能：先把所有报警块的 Priority 和 Category 导出为 CSV，在 Excel 中按矩阵和类别表批量填写，再导入回 DeltaV。这样比逐块点击更可靠，也便于版本管理。导入前务必在测试库验证，避免把 1 级报警误设为 4 级。
示例：TT-101 高报警配置
Block: PID1
Alarm: HI_ALM
Priority: 1
Category: REACTOR_SAFETY
Enable: True
Deadband: 0.5 degC
Delay: 2 s
配置完成后，用 DeltaV 的 Alarm Banner 模拟触发一次报警，确认三件事：报警是否以 1 级颜色显示、是否出现在反应器操作站、是否被正确记录到安全报警报表。若颜色或路由不对，优先检查 Category 是否选错，而不是先改 Priority。
四、配置后的验证与常见问题
配置完成后，至少做三类验证。第一类是单点验证：手动强制 TT-101 超过高限，观察 Alarm Banner 是否在 2 s 延迟后弹出 1 级红色报警，并确认报警列表按优先级排序。第二类是路由验证：确认该报警只出现在反应器操作站，不会同时推送到公用工程操作站。第三类是记录验证：在 DeltaV 报警统计中确认该报警被计入 REACTOR_SAFETY 类别，而不是默认类别。
常见问题有三种。一是优先级与类别不匹配，例如把安全联锁报警设为 4 级，导致操作员忽略；二是类别未定义就填了代码，导入时报错或报警落入默认类别；三是死区（Deadband）和延迟（Delay）设置过小，导致报警频繁抖动，即使优先级正确也会造成报警泛滥。解决顺序是：先确认类别存在，再核对优先级矩阵，最后调整死区和延迟。
最后给出一个可直接使用的配置检查表，用于每台报警块配置完成后逐项核对：
| 检查项 | 判断标准 | 示例值 |
|---|---|---|
| Priority 是否在 1～4 | 与矩阵格值一致 | 1 |
| Category 是否已定义 | 类别表中存在该代码 | REACTOR_SAFETY |
| 路由操作站是否正确 | 与类别默认路由一致 | 反应器操作站 |
| Deadband 是否合理 | 大于正常波动幅度的 1.5 倍 | 0.5 degC |
| Delay 是否合理 | 大于正常波动持续时间 | 2 s |
| 是否参与抑制 | 与类别定义一致 | 否 |
把矩阵、类别表和检查表三者配套使用，报警优先级与分类设计就从“凭感觉”变成了可评审、可复现、可审计的工程活动。DeltaV 中的 Priority 和 Category 字段只是最终落点，真正的设计工作发生在矩阵评审和类别定义阶段。