4. WinCC报警与事件归档

在WinCC生产历史数据平台中，实时报警解决的是“此刻发生了什么”，而报警归档解决的是“过去发生过什么、持续了多久、谁确认的、什么时候恢复的”。如果只做实时报警显示而不做归档，操作员离开画面后报警就消失了，事后追溯、责任界定、设备劣化趋势分析都无从谈起。因此，报警归档是历史数据平台中与过程值归档并列的另一条数据主线。

报警归档的对象：报警记录与事件记录

WinCC的报警归档由“报警记录”（Alarm Logging）运行系统组件负责。它把报警系统产生的消息按时间顺序写入归档数据库，形成两类核心记录：

• 报警消息（Alarm）：对应“到达/离开”状态的消息，例如“电机过载”到达、“电机过载”离开。它描述的是一个持续状态区间。
• 事件消息（Event）：对应一次性动作或操作，例如“操作员确认”“配方下载完成”“登录失败”。它描述的是一个时间点。

理解这个区别很重要：报警消息有“开始时间”和“结束时间”，事件消息通常只有“发生时间”。在平台侧做查询时，报警消息适合做持续时间统计，事件消息适合做操作审计。

消息块：决定归档里到底存了哪些字段

报警归档存什么，不是由数据库表结构决定的，而是由报警组态中的“消息块”决定的。消息块是消息的数据字段模板，常见的有：

消息块配置得越完整，平台侧可查询的维度就越多。但也要注意：消息块越多，归档记录越大，写入和查询开销越高。工程上建议至少保留消息编号、消息文本、报警类别、状态、时间戳、持续时间、确认用户这七项，其余按需增加。

报警周期：归档的“采样节奏”

报警周期（Alarm Cycle）不是报警的触发周期，而是报警归档的写入/刷新周期。它决定了报警状态变化被记录到归档数据库的时间粒度。常见设置如1秒、500毫秒、100毫秒。周期越短，时间分辨率越高，但数据库写入压力越大。

这里有一个容易混淆的点：报警的“到达”是由过程值触发、由报警系统实时产生的，而归档周期只影响这条消息被写入归档库的节奏。如果周期设为1秒，而报警在200毫秒内到达又离开，归档可能只记录到一次状态变化，甚至合并。因此，对于快速抖动型报警，需要更短的归档周期，或者在报警组态中启用“抖动抑制”来避免刷屏。

报警历史数据在平台中的存储结构

WinCC报警归档在本地通常以分段数据库形式存储，平台侧一般通过归档连接器或导出接口，把报警记录抽取到中心数据库。平台中建议采用“报警事实表 + 报警定义维表”的结构：

报警事实表 alarm_fact
  alarm_id        消息编号
  tag_name        关联变量名
  category        报警类别
  priority        报警级别
  state           到达/离开/确认
  start_time      开始时间
  end_time        结束时间
  duration_sec    持续秒数
  ack_user        确认用户
  ack_time        确认时间

报警定义维表 alarm_def
  alarm_id        消息编号
  message_text    消息文本
  area            所属工段
  device          设备编号
  alarm_cycle     归档周期

这样拆分的好处是：事实表只存变化记录，维表存静态描述，查询时通过alarm_id关联，既节省空间，又便于按工段、设备、类别做聚合。

查询需求：平台侧真正要回答的问题

报警归档进入平台后，查询需求通常集中在四类：

1. 时间范围查询：某天某班次发生了哪些报警，按时间排序。
2. 状态追溯：某条报警从到达、确认到离开的完整状态链。
3. 统计聚合：某设备一周内报警次数、总持续时间、平均恢复时间。
4. 关联分析：报警发生前后，相关过程值是否出现异常波动。

其中“平均恢复时间”和“报警频次TOP10”是设备劣化分析最常用的两个指标。平台侧查询时要注意：报警持续时间应由end_time减start_time计算，而不是简单累加归档周期，否则会因周期抖动产生误差。

配置要点与常见问题

实际配置时，建议按以下顺序推进：先在报警组态中定义消息块，确保编号、文本、类别、状态、时间戳、持续时间、确认用户齐全；再设置报警归档周期，对快速抖动报警取100～500毫秒，对一般工艺报警取1秒即可；然后启用报警记录归档，指定归档分段大小和备份路径；最后在平台侧建立事实表与维表，配置抽取任务。