4. WinCC报警记录与报表数据源

在生产报表中，报警数据往往比过程值更能说明“这段时间到底发生了什么”。但报警数据与趋势归档数据的来源、结构和查询方式并不相同：趋势归档来自变量记录，报警归档来自报警记录系统。如果直接把报警控件里的显示内容当作报表数据源，通常会遇到时间范围不匹配、消息块缺失、重复消息无法区分等问题。本节围绕报警归档原理、报警类别与消息块组态、归档查询接口，以及如何把报警数据整理成可进入生产报表的数据准备过程展开。

报警归档的基本原理

WinCC 的报警系统在运行时分为两个层面：报警的产生与显示，以及报警的归档。当过程变量触发报警条件时，报警系统生成一条报警消息，消息带有时间戳、报警编号、消息块内容、状态位等信息。报警控件负责实时显示，而报警归档负责把消息按时间顺序写入报警归档数据库。归档后的每条记录通常包含“到达时间”“离开时间”“确认时间”以及消息状态，例如是否已确认、是否已离开、是否为伴随消息。

需要特别注意的是，报警归档不是简单地把报警文本存成一行。一条报警从到达、确认到离开，可能经历多个状态变化，归档中会以状态位和多个时间字段记录这些变化。因此，在报表中统计“某报警发生了几次”时，通常应以到达时间计数；统计“某报警持续了多久”时，则要用离开时间减到达时间。若报警尚未离开，离开时间可能为空，计算持续时间时需要单独处理。

报警类别与消息块组态

报警类别决定了报警在系统中的行为属性，例如是否需要确认、是否进入中央归档、是否触发声光提示。常见的类别包括“错误”“警告”“系统报警”“过程控制报警”等。类别本身不是报表字段，但它会影响报警是否被归档、以何种优先级显示，以及确认行为。因此，在规划报表数据源时，应先确认哪些报警类别需要进入报表，避免把调试类、系统类报警混入生产统计。

消息块是报警消息中真正被记录和显示的内容。WinCC 的消息块分为系统块和用户块：系统块如日期、时间、编号、状态等由系统自动生成；用户块如“消息文本”“错误位置”“原因”“处理建议”等需要组态。报表中最常用的用户块通常是消息文本和错误位置，它们决定了报表中“哪条报警、发生在哪个设备”的可读性。

组态消息块时，建议遵循以下原则：消息文本应简短且唯一，便于报表分组统计；错误位置应使用统一的设备命名规则，例如“反应釜R101”“泵P201”，不要在同一字段中混用设备名和描述；原因和处理建议可以保留在报警画面中，但不必全部进入报表，否则报表字段会过于冗长。若后续需要按设备统计报警次数，错误位置字段的命名一致性比消息文本更重要。

报警归档查询接口

WinCC 提供多种方式查询报警归档，常见的有报警控件、在线表格控件、以及通过脚本或 SQL 访问归档数据库。对于生产报表，最稳妥的方式通常是通过 WinCC 的连通性软件包或归档数据库接口读取报警归档表，而不是从报警控件的显示内容中抓取。

在 WinCC 中，报警归档通常存储在 SQL Server 的归档数据库中，表名与归档名称相关。查询时一般需要指定时间范围、报警类别或报警编号。以下是一个查询报警归档的 SQL 思路示例，用于说明字段结构，实际表名和字段名需以项目组态为准：

-- 示例：按时间范围查询报警归档
SELECT
    AlarmID,          -- 报警编号
    MsgText,          -- 消息文本
    ErrorLocation,    -- 错误位置
    ArrivalTime,      -- 到达时间
    DepartureTime,    -- 离开时间
    AcknowledgeTime   -- 确认时间
FROM AlarmArchive
WHERE ArrivalTime >= '2025-01-01 08:00:00'
  AND ArrivalTime <  '2025-01-01 16:00:00'
ORDER BY ArrivalTime;

如果使用 WinCC 脚本，可以通过 AlarmLogging 对象或 WinCCAlarmControl 的查询方法获取报警数据。无论采用哪种接口，关键都是明确三个条件：时间范围、报警类别、需要的消息块。缺少任何一个条件，查询结果都可能偏离报表需求。

将报警数据纳入生产报表的数据准备

报警归档数据不能直接丢进报表，通常需要经过一次“数据准备”过程。这个过程包括字段筛选、时间对齐、状态判断和统计口径统一。下面以一个班次生产报表为例说明。

假设某班次为 08:00 到 16:00，需要统计三个指标：报警总次数、按设备统计的报警次数、未确认报警数量。原始报警归档中可能包含大量系统报警和重复消息，因此第一步是按报警类别过滤，只保留“过程控制报警”和“错误”两类；第二步是按错误位置分组，统计每个设备的报警次数；第三步是检查确认时间字段，若确认时间为空，则计入未确认报警。

在时间对齐上，需要注意报警归档时间与报表班次时间的边界。例如 07:58 到达、08:05 离开的报警，按到达时间应计入本班次，但按离开时间则可能被误判为上一班次。因此，报表统计应明确以到达时间作为归属依据，并在报表说明中注明这一口径。

数据准备完成后，通常形成一张中间表，字段包括：班次、设备名称、报警编号、消息文本、到达时间、离开时间、确认时间、是否未确认。这张中间表既可以作为报表数据源，也可以作为后续趋势分析和考核依据。对于需要长期存档的报表，建议把中间表按班次或日期分区存储，避免每次查询都扫描全量归档。

在实际工程中，报警数据准备最容易出问题的地方不是查询语法，而是统计口径。例如同一台设备在 10 分钟内反复触发同一报警 20 次，如果报表按“报警次数”统计，会得到 20 次；如果按“报警事件”统计，可能只算 1 次。因此，在报表设计阶段就应明确：是统计原始报警条数，还是统计去重后的报警事件数。前者适合分析报警频发程度，后者适合考核设备故障次数。

最后，报警数据进入生产报表后，应与过程值报表保持相同的班次、日期和设备编码体系。如果过程值报表用“R101”表示反应釜，报警报表的错误位置也必须用“R101”，否则后续无法按设备关联分析。报警记录与报表数据源的打通，本质上不是技术接口问题，而是数据规范问题：类别要分清、消息块要统一、时间口径要一致、设备编码要可关联。做到这四点，报警数据才能真正成为生产报表中有价值的一部分。