3. SCADA报警与事件数据模型

在SCADA系统中，报警与事件管理能否真正落地，取决于底层数据模型是否设计得当。如果数据模型只记录“某点越限了”，而没有状态、优先级、时间戳、确认、抑制、搁置等字段，后续的报警泛滥治理、根因分析、审计追溯都无从谈起。本节围绕报警状态模型和核心数据字段展开，目标是让读者能够设计出一张可支撑实际运行的报警/事件记录表。

一、报警状态模型：从“发生”到“消失”的完整生命周期

报警不是一个瞬时动作，而是一个有生命周期的状态对象。ISA-18.2和IEC 62682给出了被广泛采用的报警状态模型，其核心状态包括：未确认未消失（UNACK_ALM）、已确认未消失（ACK_ALM）、未确认已消失（UNACK_RTN）、已确认已消失（ACK_RTN，即正常态），以及搁置（SHELVED）和抑制（SUPPRESSED）两类特殊状态。

理解这个模型的关键在于两个独立维度：报警条件是否仍然存在（是否返回正常），以及操作员是否已确认。这两个维度组合出四种基本状态。例如，一个温度高报警触发后，若操作员点击确认但温度仍高，则进入ACK_ALM；若温度回落但操作员尚未确认，则进入UNACK_RTN——这个状态常被忽视，但它意味着“报警已消失但无人知晓”，在审计中往往被视为风险点。

状态迁移由事件驱动：报警触发（ALM）、报警返回（RTN）、操作员确认（ACK）、搁置（SHELVE）、抑制（SUPPRESS）等。每次迁移都应产生一条事件记录，而不是覆盖原记录。这一点直接决定了数据表的设计：报警表保存“当前状态”，事件表保存“状态迁移历史”。

二、事件分类：报警、事件、操作记录要分开

很多SCADA项目把所有信息都塞进一张“报警表”，结果查询缓慢、统计口径混乱。正确的做法是按语义分类：报警（Alarm）是要求操作员响应的异常状态；事件（Event）是系统状态变化但不一定需要响应，如设备启停、模式切换；操作记录（Operator Action）是人员操作日志，如确认、搁置、参数修改；系统事件（System Event）是通信中断、采集超时等平台级信息。

分类字段建议使用枚举值而非自由文本，例如：category 取值为 ALARM / EVENT / OP_ACTION / SYS_EVENT。这样在报表中可按类别聚合，也便于设置不同的保留周期——报警通常保留1~3年，操作记录可能需要保留5年以上以满足审计要求。

三、优先级：不是“重要程度”，而是“响应时限”

优先级常被误解为“这个报警重不重要”。在ISA-18.2中，优先级应由后果严重度和允许响应时间共同决定。通常分为四级：P1（紧急，响应时间<1分钟）、P2（高，<5分钟）、P3（中，<30分钟）、P4（低，<2小时或仅记录）。

设计字段时，除了 priority 整数值，还应保留 priority_source（优先级来源：设计预设/动态计算/人工调整）和 priority_reason。这样在复盘时能回答“为什么这条报警是P1”。一个实用的经验是：P1报警数量应控制在总报警量的5%以内，否则操作员会产生“狼来了”效应。

四、时间戳：至少三个，缺一不可

时间戳是报警数据模型中最容易被简化、也最容易出问题的字段。建议至少记录三个时间：

• occur_time（发生时间）：现场设备或RTU检测到异常的时刻，由采集端打标；
• receive_time（接收时间）：SCADA服务器收到该信号的时刻；
• ack_time（确认时间）：操作员点击确认的时刻。

occur_time与receive_time的差值反映了通信链路延迟。在电力SCADA中，若该差值持续大于2秒，往往意味着通道拥塞或规约轮询周期过长。所有时间戳应统一使用带时区的ISO 8601格式存储，例如 2025-03-15T08:23:41.250+08:00，避免夏令时或跨区部署时出现歧义。

五、确认、抑制与搁置：三个容易混淆的字段

确认（Acknowledge）是操作员对报警的“已阅”标记，字段为 ack_flag、ack_user、ack_time、ack_comment。确认不改变报警条件是否存在的判断。

抑制（Suppress）是设计层面的屏蔽，通常由组态决定，例如在设备检修期间通过逻辑条件自动抑制相关报警。字段包括 suppress_flag、suppress_reason、suppress_by。抑制应记录原因，且不应由操作员随意开启。

搁置（Shelve）是操作员临时屏蔽某条报警的行为，必须有期限。字段包括 shelve_flag、shelve_user、shelve_start、shelve_duration、shelve_expire。搁置到期后应自动恢复报警，且搁置期间若报警再次触发，应记录“被搁置的报警”以供审计。

六、核心数据字段设计示例

综合以上概念，一张可落地的报警事件表至少应包含以下字段。以下为示例结构，实际项目中可根据数据库类型调整字段长度和索引策略。

CREATE TABLE alarm_event (
  event_id        BIGINT PRIMARY KEY,
  tag_name        VARCHAR(64)  NOT NULL,   -- 测点名，如 BOILER1_TEMP
  category        VARCHAR(16)  NOT NULL,   -- ALARM/EVENT/OP_ACTION/SYS_EVENT
  alarm_type      VARCHAR(32),             -- HI/HIHI/LO/LOLO/DEV/ROC
  priority        TINYINT      NOT NULL,   -- 1~4
  priority_source VARCHAR(16),             -- DESIGN/DYNAMIC/MANUAL
  state           VARCHAR(16)  NOT NULL,   -- UNACK_ALM/ACK_ALM/UNACK_RTN/ACK_RTN
  occur_time      TIMESTAMP(3) NOT NULL,
  receive_time    TIMESTAMP(3),
  ack_time        TIMESTAMP(3),
  ack_user        VARCHAR(32),
  ack_comment     VARCHAR(256),
  rtn_time        TIMESTAMP(3),
  shelve_flag     BOOLEAN DEFAULT FALSE,
  shelve_user     VARCHAR(32),
  shelve_expire   TIMESTAMP(3),
  suppress_flag   BOOLEAN DEFAULT FALSE,
  suppress_reason VARCHAR(128),
  limit_value     DECIMAL(12,4),           -- 报警限值
  actual_value    DECIMAL(12,4),           -- 触发时实际值
  unit            VARCHAR(16),
  source_node     VARCHAR(64)              -- 采集节点/RTU标识
);

其中 state 字段只保存当前状态，而每次状态迁移应写入独立的事件历史表 alarm_event_history，包含 event_id、from_state、to_state、transition_time、operator。这样既能快速查询当前报警，又能完整追溯生命周期。

七、从字段到运行：一个判断示例

假设某锅炉温度高报警在 08:23:41.250 触发，occur_time 与 receive_time 相差 3.2s，优先级为P2，操作员在 08:25:10 确认，温度在 08:31:05 回落。此时状态迁移为：NORMAL → UNACK_ALM → ACK_ALM → ACK_RTN。若操作员在确认前就搁置了该报警，则状态进入SHELVED，且 shelve_expire 应设置为合理期限（如30分钟）。复盘时，通过 occur_time 与 receive_time 的差值可判断通信是否正常，通过 ack_time 与 occur_time 的差值可评估操作员响应速度，通过 shelve_flag 可识别是否存在过度搁置。

数据模型的价值不在于字段多，而在于每个字段都能回答一个运维或审计问题。设计时先问“这个字段将来会被谁、在什么场景下查询”，再决定是否保留，往往比照搬模板更有效。