📚 课程目录第3章报警系统核心概念

3. 报警系统核心概念

在 Ignition 中，报警不是“一个布尔量变红”这么简单，而是一套从现场信号到操作员响应的完整链路。理解报警类型、优先级、状态机、报警管道、存储与确认机制，是后续做报警报表和权限工程的基础。只有把这条链路看清楚，才能知道“谁在什么时候、因为什么、对哪条报警做了什么动作”，报表才有意义，权限才有边界。

一、报警类型：不同来源，不同语义

Ignition 的报警类型决定了报警如何被触发、如何被评估以及如何呈现。常见类型包括：

位报警（Bit Alarm）：绑定一个布尔量或整数的某一位，0/1 变化即触发，适合“运行/停止”“故障/正常”这类离散状态。
模拟量报警（Analog Alarm）：绑定一个数值标签，按阈值触发，支持高限、高高限、低限、低低限、偏差、变化率等。
集合报警（Setpoint / Multi-State）：按一组预设状态或枚举值触发，适合“设备模式”“批次阶段”等。
脚本报警（Script Alarm）：由脚本或表达式动态产生，适合复杂逻辑或外部系统联动。
系统报警（System Alarm）：由 Ignition 自身产生，如数据库连接失败、网关通信中断、标签提供者异常等。

报警类型决定了报警的“触发源”和“评估方式”。在报表中，类型字段往往用于区分“工艺报警”和“系统报警”，因为两者的处理优先级和权限要求完全不同。

二、优先级：决定响应顺序与通知策略

优先级是报警的“紧急程度标签”。Ignition 默认提供 Diagnostic、Low、Medium、High、Critical 五级，也可以自定义。优先级影响：报警横幅颜色、声音、是否弹出、是否发送邮件/短信、是否进入报表统计。

优先级	典型场景	响应要求	通知方式
Critical	安全联锁、设备损坏风险	立即处理	声音+弹窗+短信
High	关键工艺参数越限	5 分钟内确认	声音+弹窗
Medium	一般工艺偏差	当班处理	横幅+邮件
Low	提示性信息	记录即可	仅记录
Diagnostic	调试、维护信息	不要求响应	仅日志

优先级不是“越少越好”，而是要与工艺风险匹配。如果所有报警都是 High，操作员会逐渐麻木，这就是典型的“报警泛滥”问题。

三、状态机：报警从产生到清除的完整生命周期

Ignition 报警遵循一个明确的状态机。理解状态机，才能理解“确认”和“清除”的区别。核心状态包括：

Clear（正常）：条件未满足，报警未激活。
Active（激活）：条件满足，报警产生，但操作员尚未确认。
Acknowledged（已确认）：操作员已确认，但条件仍然存在。
Cleared（已清除）：条件恢复，报警不再激活。

状态之间的迁移关系是：Clear → Active → Acknowledged → Cleared。如果条件在确认前就恢复，则可能直接进入 Cleared，但历史记录中仍会保留“未确认”标记。这个标记在报表中非常关键，因为它代表“操作员漏确认”。

四、报警管道：从标签到操作员的信号链

报警管道（Alarm Pipeline）描述报警从产生到呈现的完整路径。典型链路如下：

标签提供者：OPC UA、Modbus、SQL 等采集现场数据。
报警评估：Ignition 按报警配置评估条件，决定是否触发。
报警状态管理：维护 Active、Ack、Clear 等状态。
报警通知：通过 Alarm Status Table、报警横幅、邮件、短信等呈现。
报警存储：写入 SQL 数据库或报警日志，供报表查询。

这条管道中任何一环出问题，都会导致“报警不显示”或“报表查不到”。例如，数据库连接失败时，报警仍会在客户端显示，但无法写入历史表，报表就会缺失记录。

排查报警问题时，建议按管道顺序逐段检查：标签值是否变化 → 报警是否触发 → 状态是否正确 → 通知是否发出 → 存储是否成功。不要一上来就查数据库。

五、报警存储与确认机制：报表与权限的数据基础

Ignition 的报警存储通常依赖 SQL 数据库。报警系统会自动创建报警状态表和历史表，记录报警名称、优先级、状态、时间戳、确认人、确认时间等字段。确认机制则通过客户端操作完成，确认动作会写入数据库，并带上当前登录用户。

-- 报警历史表典型字段（简化）
AlarmName        VARCHAR(255)
Priority         VARCHAR(50)
State            VARCHAR(50)   -- Active / Acknowledged / Cleared
ActiveTime       DATETIME
AckTime          DATETIME
ClearTime        DATETIME
AckUser          VARCHAR(100)
AckNote          VARCHAR(500)

确认机制与权限工程直接相关：谁可以确认、谁可以清除、谁只能查看，都由 Ignition 的角色和权限控制。例如，操作员可以确认 Low/Medium 报警，但 High/Critical 报警可能需要班长或工程师角色才能确认。这些规则必须在报警配置和项目权限中同时落地。

常见误区：只配置了报警，却没有配置确认权限。结果是所有登录用户都能确认 Critical 报警，审计时无法追溯责任。正确做法是把确认动作与用户角色绑定，并在报表中输出 AckUser 字段。

六、案例：一条 High 报警的完整生命周期

假设反应釜温度标签 TT-101 超过 High 限 120°C：

10:00:00 温度达到 121°C，报警触发，状态 Active，优先级 High。
10:00:05 操作员在 Alarm Status Table 中点击确认，状态变为 Acknowledged，AckUser 记录为 operator01。
10:03:20 温度回落到 118°C，报警清除，状态变为 Cleared。
报表统计：确认延迟 5 秒，持续时长 3 分 20 秒，确认人 operator01。

如果操作员在 10:03:20 之前没有确认，则报警会以“未确认清除”记录，报表中会标记为漏确认。这类记录是报警管理评审的重点。

七、复盘要点

报警类型决定触发方式，优先级决定响应策略，两者不能混为一谈。
状态机是理解确认与清除的关键，报表必须记录三个时间戳。
报警管道是排查问题的路线图，存储和通知是两条并行支路。
确认机制必须与权限工程结合，否则审计和报表都会失真。

掌握这些核心概念后，后续配置报警报表时，就能清楚地知道该查哪些表、该统计哪些字段、该给哪些角色分配确认权限。