3. 报警系统设计原则与标准
报警系统不是“把能报的都报出来”，而是要在异常发生时，用最少的注意力成本把操作员引导到真正需要干预的偏差上。ISA 18.2 与 EEMUA 191 两部标准解决的正是这个问题：前者给出报警系统全生命周期的管理框架与量化指标，后者给出以人为中心的报警设计工程方法。在 Experion 中，这些要求最终要落到报警属性、优先级、抑制逻辑、报警泛滥治理和 KPI 监控等具体配置上。
一、两部标准各自管什么
ISA 18.2《Management of Alarm Systems for the Process Industries》的核心贡献是把报警系统当作一个需要持续管理的资产，定义了从识别、设计、实施、运行、维护到监控与评估、变更管理的完整生命周期，并给出关键绩效指标：每十分钟可接受的报警数、每小时的报警数、报警优先级分布、报警泛滥（Alarm Flood）定义、陈旧报警（Stale Alarm）比例、抖动报警（Chattering Alarm）比例等。它回答的是“报警系统应该被管成什么样”。
EEMUA 191《Alarm Systems: A Guide to Design, Management and Procurement》更偏工程实现，强调报警是对操作员“需要响应”的提示，提出报警优先级应由后果严重度与允许响应时间共同决定，并给出报警数量、优先级分布、泛滥判据、报警处理能力等可操作的目标值。它回答的是“报警应该怎么设计才不压垮人”。
两者在 Experion 中的关系可以概括为：ISA 18.2 提供管理框架与 KPI 口径，EEMUA 191 提供设计准则与优先级方法，Experion 提供承载这些要求的组态与监控手段。
二、报警哲学：先定义“什么才配叫报警”
报警哲学是设计规范的上游。它必须明确：报警只用于提示操作员需要采取行动或做出判断的异常状态；过程参数偏离但无需操作员响应的，应作为提示或趋势，不进入报警系统；设备状态、联锁动作、诊断信息要区分对待，不能与过程报警混在同一优先级池中。
在 Experion 中，报警哲学通常体现为一组可执行的规则：每个报警必须有明确的起因、后果、允许响应时间和操作员动作；没有操作员动作的报警应删除或降级为事件；同一根因引发的多个报警应通过报警抑制或因果矩阵归并；报警优先级不能由“重要/不重要”主观决定，而应由后果严重度和响应时间窗口推导。
报警哲学落地检查要点：
- 每条报警是否写明了操作员应执行的动作？
- 该动作是否在允许响应时间内可完成？
- 报警是否由独立于控制回路的偏差判断触发？
- 是否存在同一根因产生多条报警而未做归并？
- 报警优先级是否与后果严重度、响应时间一致？
三、优先级设计：EEMUA 191 的二维判据
EEMUA 191 建议用“后果严重度 × 允许响应时间”确定优先级。后果越严重、允许响应时间越短，优先级越高。典型做法是划分三个优先级：紧急（Priority 1）、高（Priority 2）、低（Priority 3）。在 Experion 中，优先级不是显示颜色那么简单，它同时影响报警声音、报警列表排序、报警横幅行为、报警抑制策略和操作员响应统计。
一个常见的教学示例是：某反应器温度高报警，若允许响应时间为 5 分钟且后果为设备损坏，可定为 Priority 2；若同一温度继续上升将触发安全联锁并导致停车，允许响应时间 1 分钟，则应定为 Priority 1。这里的关键不是数值本身，而是“后果—时间”二维判据必须一致地应用到所有报警上，否则优先级分布会失真。
四、报警泛滥与抑制：从指标到组态
ISA 18.2 与 EEMUA 191 都关注报警泛滥。EEMUA 191 给出的可接受目标是：正常运行时平均每 10 分钟不超过 1 条报警；报警泛滥时，10 分钟内超过 10 条报警即视为泛滥。ISA 18.2 进一步要求对泛滥进行根因分析，而不是简单调大死区。
在 Experion 中，治理报警泛滥通常组合使用以下手段：报警死区与延时、报警抑制（Suppression）、报警搁置（Shelving）、报警归并（Alarm Grouping）、因果矩阵（Cause and Effect Matrix）以及基于状态的报警屏蔽。需要强调的是，抑制和搁置必须有时限、有审批、有记录，否则会变成“把报警藏起来”。
五、报警设计规范在 Experion 中的具体落地
把标准转成 Experion 可执行的规范，通常要落到以下几类配置对象上。
报警属性。每条报警需要定义：报警类型（偏差、高高、低低、变化率等）、优先级、死区、延时、报警限值、是否参与报警统计。死区和延时的设置要基于过程噪声和响应时间，不能为了减少报警数而随意放大，否则会掩盖真实异常。
报警抑制与搁置。抑制用于“已知工况下不应报警”的场景，例如开车阶段、设备切换、维护模式；搁置用于操作员临时屏蔽某条报警，必须有时间限制和审批记录。Experion 中可通过报警抑制组、状态驱动抑制和搁置权限控制实现。
报警归并与因果矩阵。当同一根因引发多条报警时，应通过因果矩阵或报警组把多条报警归并为一条根因报警，避免操作员在报警列表中反复确认同一问题。
报警泛滥治理。当 10 分钟内报警数超过 10 条时，应触发泛滥分析：检查是否有报警抖动、是否有报警限值设置不合理、是否有工况切换未做抑制、是否有报警优先级分布失衡。治理顺序通常是先消除抖动和陈旧报警，再优化限值和死区，最后才考虑抑制。
六、KPI 监控与持续改进
标准落地不是一次性工程。ISA 18.2 要求定期评估报警系统性能，EEMUA 191 给出了可接受目标值。在 Experion 中，应建立报警 KPI 报表，至少监控：每 10 分钟报警数、报警泛滥次数、优先级分布、陈旧报警比例、抖动报警比例、操作员响应时间、抑制和搁置使用率。
当 KPI 偏离目标时，应回到报警哲学和设计规范进行根因分析，而不是直接调整报警限值。例如，若 Priority 1 报警占比过高，说明优先级判据执行不一致；若陈旧报警比例高，说明报警限值或死区设置不合理；若泛滥频繁，说明抑制策略或工况切换管理不到位。
实践建议：在 Experion 中建立报警 KPI 报表时，建议按装置、班组、工况分别统计，避免平均值掩盖局部问题。报警泛滥治理应优先处理高频抖动报警和陈旧报警，再处理优先级分布失衡，最后才考虑新增抑制逻辑。
总结来看，ISA 18.2 与 EEMUA 191 在 Experion 中的落地，本质是把“报警应该是什么”转化为“报警在系统中怎么配、怎么管、怎么评”。报警哲学决定边界，优先级判据决定排序，抑制与归并决定可操作性，KPI 监控决定持续改进方向。四者缺一，报警系统就会重新滑回“报警太多、操作员不看”的老路。