2. AVEVA报警系统架构解析
报警风暴治理的第一步不是调参数，而是把报警从产生到落库的整条链路看清楚。AVEVA（原 Wonderware）体系中的报警并非由单一组件产生，而是由现场控制器、通信驱动、采集服务、报警服务器、客户端与历史库共同构成的一条多级数据通路。任何一级出现瓶颈、配置错误或时间基准不一致，都会在风暴场景下被放大成"报警刷屏"或"报警丢失"。本节按数据实际流动的顺序，逐级拆解这条链路。
一、报警源：报警在哪里"出生"
报警源是报警事件的原始产生点，决定了报警的语义、时间戳和优先级。在典型工程中，报警源主要有三类：
- PLC/DCS 内部报警：由控制器逻辑判断后置位报警位，例如某泵的"运行超时"位、某罐的"高高液位"位。这类报警的语义由控制程序定义，AVEVA 侧只负责读取。
- AVEVA 侧计算报警：由 InTouch 或 System Platform 的脚本、表达式或 OMI 逻辑生成，例如"同一区域内 3 台泵同时故障"这类组合条件报警。
- 设备与系统级报警：来自通信驱动、OPC 服务器或第三方系统的状态报警，例如"通信中断""驱动重连"。
报警源的关键属性包括：报警标签名（Tag）、报警类型（离散/模拟量/偏差）、优先级（1～999，数值越小越紧急）、报警状态（Active/Inactive、Acked/Unacked）以及源时间戳。源时间戳是后续判断"报警是否真实同时发生"的基础，必须与采集链路的时间基准保持一致。
二、采集链路：从现场到报警服务器的通道
采集链路负责把报警源的状态变化搬运到报警服务器。在 AVEVA 架构中，这条链路通常由以下环节组成：
- 通信驱动：如 DAServer、DIAServer 或 OPC UA 客户端，负责与 PLC/DCS 建立会话，周期性或订阅式读取数据。
- 数据采集服务：将驱动读到的原始值转换为 AVEVA 内部标签值，并写入内存标签库（Tag Engine）。
- 报警检测引擎：在标签值更新时，按报警配置（限值、死区、延时、优先级）判断是否产生报警状态变化。
采集链路的核心参数是扫描周期与死区（Deadband）。扫描周期决定报警被发现的延迟，死区决定模拟量报警的抖动抑制程度。例如某温度报警限值为 80℃，死区设为 2℃，则温度升到 80℃ 时报警置位，只有降到 78℃ 以下才复位。若死区过小，温度在限值附近波动会反复触发报警，是风暴的常见诱因之一。
三、报警服务器：报警的"中枢"
报警服务器（Alarm Server / Alarm Provider）是整条链路的核心，承担报警的接收、状态管理、分发与持久化。它维护每个报警标签的当前状态机，并对外提供报警订阅接口。报警服务器的主要职责包括：
- 接收报警检测引擎上报的状态变化，更新报警状态机；
- 按优先级、区域、类型等条件向客户端分发报警；
- 将报警事件写入历史库；
- 管理确认（Ack）、抑制（Suppress）、屏蔽（Disable）等操作。
报警服务器通常以服务形式运行，其性能瓶颈往往出现在报警速率上。当每秒报警事件数超过服务器处理能力时，会出现报警排队、延迟甚至丢弃。因此，评估报警服务器容量时，必须关注"峰值报警速率"而非"平均速率"。
四、客户端与历史库：报警的"出口"
客户端（InTouch View、OMI 客户端、Web 客户端）是操作员看到报警的界面。它通过订阅方式从报警服务器获取报警，并按报警控件（Alarm Banner、Alarm Grid）的配置显示。客户端的刷新频率、过滤条件和排序方式直接影响操作员的感知负荷。在风暴场景下，客户端若未设置合理的过滤（如只显示优先级 1～200 的未确认报警），操作员会被大量低优先级报警淹没。
历史库（Historian / Alarm DB）负责报警事件的长期存储，供事后分析与审计。报警事件写入历史库时，通常包含标签名、报警状态、优先级、源时间戳、服务器时间戳、确认用户与确认时间等字段。历史库的写入延迟和存储策略（如压缩、归档周期）会影响报警回放与统计的准确性。
五、数据流全景与关键观察点
把上述组件串起来，报警数据流可以概括为：报警源 → 通信驱动 → 采集服务 → 报警检测 → 报警服务器 → 客户端/历史库。下面用一张结构图展示各组件的位置、连接方向与关键参数，便于在排障时快速定位瓶颈所在。
从图中可以看到，报警数据流是一条"源—采集—服务器—出口"的链式结构，每一级都有自己的关键参数和瓶颈形态。实际排障时，建议按数据流方向逐级确认：先看报警源是否在抖动，再看采集链路的扫描周期与死区是否合理，然后检查报警服务器的峰值速率与队列，最后确认客户端过滤与历史库写入是否正常。只有把这条链路看清楚，后续的报警风暴治理才有明确的着力点。