2、基础知识：告警系统的基本组成、本地告警与云端告警的区别、常见告警类型与触发条件

在构建Edge AI告警策略之前，必须先厘清告警系统的底层逻辑。告警不是简单的“发现问题就喊一声”，而是一条从数据采集、状态判断、策略匹配到渠道触达的完整链路。对于边缘计算场景，告警系统的设计还面临带宽、延迟、离线可用性等特殊约束。本节将系统拆解告警系统的基本组成，对比本地告警与云端告警的架构差异，并梳理常见告警类型与触发条件的设定方法，为后续章节的规则编写和渠道配置打下基础。

2.1 告警系统的基本组成

一个完整的告警系统无论部署在边缘还是云端，都包含五个核心模块：数据采集层、状态评估层、规则决策层、通知执行层和反馈闭环层。数据采集层负责从传感器、设备总线或AI推理结果中获取原始数据；状态评估层对数据进行清洗、特征提取和初步判断；规则决策层根据预设的阈值、逻辑表达式或机器学习模型决定是否触发告警；通知执行层将告警消息通过声光、短信、邮件或Webhook发送给相关人员或系统；反馈闭环层则记录告警的处理状态，用于后续的统计分析和规则优化。

在Edge AI场景中，数据采集层往往运行在资源受限的嵌入式设备上，因此需要采用轻量级的采集策略。例如，使用DMA（直接内存访问）方式读取传感器数据，减少CPU占用；或者采用事件驱动的方式，仅在数据变化超过一定幅度时才上报。状态评估层则可以利用边缘设备上的NPU或GPU进行初步的AI推理，将推理结果（如目标检测的置信度、分类结果的概率分布）作为告警判断的输入特征。

组成模块	核心职责	边缘侧实现	云端侧实现
数据采集层	获取原始信号或推理结果	GPIO中断、I2C/SPI读取、本地缓存	MQTT/HTTP接收、Kafka消息队列
状态评估层	数据清洗、特征提取、初步判断	滑动窗口均值、差分计算、轻量AI模型	流处理框架（Flink/Spark）
规则决策层	匹配触发条件，决定是否告警	本地规则引擎（如Node-RED、C规则表）	云规则引擎（如AWS IoT Events）
通知执行层	将告警送达目标	GPIO驱动蜂鸣器、LED、本地日志	短信网关、邮件服务、钉钉/企微Webhook
反馈闭环层	记录处理状态，优化规则	本地Flash存储告警记录	时序数据库存储、告警分析看板

2.2 本地告警与云端告警的区别

本地告警和云端告警并非互斥关系，而是互补的两层防线。理解它们的本质区别，有助于在具体项目中合理分配告警职责。

本地告警（边缘侧）的核心优势在于低延迟和离线可用性。告警判断在设备本地完成，从数据采集到触发通知的端到端延迟通常在毫秒级。即使网络中断，本地告警依然可以正常工作。例如，在工业设备监控中，当电机轴承温度超过90°C时，边缘控制器应立即切断电源并触发声光报警，这个过程不能依赖云端指令。本地告警的局限性在于计算资源有限，难以执行复杂的聚合分析和跨设备关联判断。

云端告警（中心侧）的优势在于全局视野和复杂规则。云端可以汇聚多个边缘节点的数据，执行跨设备、跨时间窗口的关联分析。例如，判断“同一车间内超过3台设备同时出现振动异常”这种组合条件，在单台边缘设备上无法完成。云端告警还能利用历史数据进行趋势预测，提前发现潜在故障。但云端告警依赖网络连接，存在传输延迟和带宽成本，且一旦网络中断，云端告警将完全失效。

对比维度	本地告警	云端告警
端到端延迟	毫秒级（<10ms）	秒级（1-10s）
网络依赖	完全离线可用	必须在线
计算能力	受限（MCU/轻量CPU）	充足（可跑复杂模型）
数据范围	单设备或本地局域网	跨区域、跨设备全局数据
规则复杂度	简单阈值、基本逻辑	复杂事件处理、机器学习
典型场景	紧急停机、安全联锁	运维工单、趋势预警

2.3 常见告警类型与触发条件

在Edge AI项目中，告警类型可以归纳为四大类：阈值告警、变化率告警、状态告警和AI事件告警。每种类型都有其适用的场景和触发条件设计方法。

2.3.1 阈值告警

阈值告警是最基础也最常用的告警类型。它通过比较实时数据与预设的上下限来判断是否触发。阈值告警的关键在于阈值的设定，不能简单地拍脑袋决定。推荐使用统计过程控制（SPC）方法：采集正常运行状态下的数据，计算均值和标准差，将阈值设定为均值±3σ（标准差）。例如，某设备正常运行时电流均值为10A，标准差为0.5A，则高阈值设为11.5A，低阈值设为8.5A。

// 阈值告警伪代码示例
float current = read_current_sensor();
float threshold_high = 11.5;
float threshold_low = 8.5;

if (current > threshold_high || current < threshold_low) {
    trigger_alarm("电流越限", current);
}

2.3.2 变化率告警

变化率告警关注的是数据的变化速度，而非值。这在检测突发性故障时非常有效。例如，温度在1分钟内上升超过5°C，可能预示着散热系统失效或轴承磨损加剧。变化率告警的计算通常采用滑动窗口差分法：

// 变化率计算
float temp_now = read_temp();
float temp_prev = read_temp_from_buffer(60); // 60秒前的数据
float rate = (temp_now - temp_prev) / 60.0;  // °C/s

if (rate > 0.083) {  // 5°C/min = 0.083°C/s
    trigger_alarm("温度上升过快", rate);
}

2.3.3 状态告警

状态告警针对的是设备或系统的运行状态变化，而非连续数值。常见的状态告警包括：设备离线、看门狗超时、通信链路中断、配置变更等。状态告警的触发条件通常是布尔逻辑或枚举值匹配。在Edge AI场景中，特别要注意心跳机制的设计：边缘设备定期向云端发送心跳包，如果云端在设定时间内未收到心跳，则判定设备离线并触发告警。

2.3.4 AI事件告警

AI事件告警是Edge AI特有的告警类型。它基于模型推理结果触发，例如：视频流中检测到人员闯入、工业质检中识别出产品缺陷、音频分析中检测到异常声音。AI事件告警的触发条件不仅包括事件类型，还包括置信度阈值。例如，只有当目标检测的置信度超过0.85时才触发告警，避免误报。

2.4 案例拆解：某工厂设备预测性维护告警系统

下面通过一个实际案例，展示如何综合运用上述告警类型和触发条件设计一个完整的Edge AI告警系统。

背景与约束：某汽车零部件工厂有20台CNC加工中心，每台设备配备振动传感器、温度传感器和电流传感器。工厂要求：1）设备轴承故障需在发生前2小时预警；2）紧急停机必须在100ms内完成；3）车间网络不稳定，经常断线；4）运维团队只有3人，需要控制告警数量。

初始现象与目标：此前采用纯云端告警，经常出现网络延迟导致告警滞后，且误报率高达40%，运维人员产生“告警疲劳”。目标是将误报率降低到10%以下，同时保证紧急告警的实时性。

关键输入数据：振动传感器采样频率为20kHz，温度采样频率为1Hz，电流采样频率为10Hz。AI模型在边缘设备上运行，每5秒输出一次轴承健康度评分（0-100分）。

分析判断过程：

1. 分级告警设计：将告警分为三级。一级（紧急）：轴承健康度评分<30或振动幅值超过12mm/s，触发本地继电器断电+声光报警；二级（预警）：健康度评分30-50或温度变化率>3°C/min，触发本地日志+云端工单；三级（提示）：健康度评分50-70或电流波动超过10%，仅记录日志，不主动通知。
2. 本地/云端分工：一级告警完全在本地执行，不依赖网络。二级告警在本地生成，通过MQTT协议上报云端，云端创建运维工单。三级告警仅存储在本地，定期批量上传。
3. 触发条件优化：针对AI事件告警，采用“连续3次评分低于阈值才触发”的确认机制。同时设置抑制规则：设备处于维护模式时，所有告警自动抑制。

实际操作步骤：

# 边缘侧规则配置（简化示例）
rule:
  - name: "紧急停机"
    condition: "health_score < 30 OR vibration > 12"
    action: "relay_off + local_alarm"
    debounce: "0ms"
  - name: "轴承预警"
    condition: "health_score < 50 AND temp_rate > 3"
    action: "mqtt_publish + log"
    debounce: "30s"
  - name: "维护抑制"
    condition: "maintenance_mode == true"
    action: "suppress_all"

结果对比：实施分级告警后，误报率从40%降至8%。一级告警的响应时间稳定在80ms以内。由于三级告警不主动通知，运维人员每天处理的告警数量从平均50条降至8条，告警疲劳问题得到有效缓解。

风险与代价：本地告警规则的维护需要现场工程师具备一定的编程能力。初期部署时，阈值设定需要反复调优，建议预留2周的观察期。另外，本地Flash存储告警日志时，要注意磨损均衡，建议使用环形缓冲区并定期导出。

复盘经验：告警系统的设计不是一次性的，需要持续迭代。建议每月回顾一次告警记录，分析哪些告警是有效的、哪些是重复的，据此调整阈值和抑制规则。同时，将AI模型的置信度阈值与告警级别关联，模型更新后需要重新验证告警触发条件。

2.5 常见误区与总结

在告警系统设计中，以下误区需要特别警惕：

• 误区一：告警越多越好。实际上，过多的告警会导致运维人员麻木，真正重要的告警反而被淹没。应遵循“少而精”的原则，通过分级和抑制规则控制告警数量。
• 误区二：阈值设定后一成不变。设备老化、季节变化、工况调整都会影响数据的正常范围。阈值应支持动态调整，或采用自适应算法（如基于滑动窗口的百分位数）。
• 误区三：忽略告警去重。同一故障可能在短时间内触发多次告警。必须设计去重机制，例如在10分钟内相同原因的告警只发送一次，或者合并为一条包含次数的汇总告警。
• 误区四：本地告警和云端告警完全独立。两者应共享规则配置和告警记录，云端可以定期下发更新后的阈值到边缘设备，边缘设备也可以将本地告警的处置结果反馈到云端。