3. 报警系统总体架构设计

养殖场异常报警与远程通知系统并不是“一个传感器加一个手机App”那么简单。它是一条从现场物理量到人员响应的完整链路：温度、湿度、氨气浓度、风机电流、水表流量等信号先被采集，再经过边缘侧的清洗与初判，进入报警规则引擎做条件组合与等级判定，最后由通知网关按渠道和值班策略送达用户终端。任何一个环节设计不当，都会造成漏报、误报或“报了没人管”。本节围绕这条端到端架构，说明各模块的职责边界与数据流走向。

一、五层架构与职责划分

从工程实现角度，可以把系统划分为五个逻辑层，层与层之间通过明确定义的数据契约衔接，便于独立部署和替换。

• 采集层：由温湿度传感器、氨气/二氧化碳传感器、风速传感器、电表与电流互感器、水表、料塔称重、门磁与断电检测器等组成。职责是把物理量转换为带时间戳的数值，并通过 Modbus RTU、LoRa、NB-IoT 或 MQTT 上报。采集层只负责“测得准、传得到”，不做业务判断。
• 边缘处理层：部署在猪舍/鸡舍旁的边缘网关或工控机上。职责包括数据校验（量程越界、跳变过滤）、单位统一、短时缓存与断网续传、本地阈值初判和本地声光报警。边缘层是断网时系统仍能“喊一声”的关键保障。
• 报警规则引擎：系统的“大脑”。负责把单点数值转化为有语义的报警事件，包括阈值比较、持续时间判定、多条件组合、变化率判断、设备离线判定，以及报警等级划分与去重抑制。
• 通知网关：负责“送给谁、用什么送、送几次”。它维护联系人、值班表、升级策略，对接短信、电话语音、App推送、微信、邮件等通道，并记录送达状态。
• 用户终端：场长、饲养员、兽医的手机App、微信小程序、值班室大屏与声光报警器。终端负责呈现、确认、处置反馈，形成闭环。

需要强调的是，规则引擎与通知网关必须分离。规则引擎回答“这是不是异常、多严重”，通知网关回答“该通知谁、怎么通知、通知到没有”。二者耦合在一起，会导致调整通知渠道时被迫改动判定逻辑，后期维护成本很高。

二、数据流与关键字段

整条链路的数据形态发生三次变化：原始测点数据 → 清洗后的标准数据 → 报警事件 → 通知消息。每一次转换都应保留可追溯的标识，否则事后排查“为什么没报警”会非常困难。

采集层上报的原始数据建议至少包含：设备ID、舍号、测点类型（如 temp、nh3、fan_current）、数值、单位、采集时间、网关接收时间。边缘层在此基础上补充质量标记，例如 quality: good / suspect / bad，当数值超出量程或连续跳变时标记为 suspect，规则引擎对 suspect 数据不直接触发高等级报警，而是转为“传感器异常”类事件。

规则引擎输出的报警事件应包含：事件ID、规则ID、报警等级、触发值、持续时长、首次触发时间、当前状态。状态机通常为“触发 → 已确认 → 已恢复”，另有“误报”分支。通知网关消费事件，生成通知消息并记录每个通道的送达结果，例如短信已提交、电话已接通、App已读。

三、规则引擎的判定逻辑示例

以育肥猪舍夏季高温报警为例，若只设“温度 > 30℃ 即报警”，风机刚启动时的短暂升温会造成大量误报。更合理的做法是组合持续时间与关联条件：

规则：夏季高温预警
条件：
  temp >= 28.0 ℃  持续 10 分钟
  且 fan_current < 0.5 A（该舍风机未运行）
等级：严重
动作：短信 + 电话呼叫值班饲养员；15 分钟未确认则升级至场长
恢复条件：temp < 27.0 ℃ 持续 5 分钟

这里引入了三个工程要点。第一，持续时间用于过滤瞬时波动，避免传感器抖动触发报警。第二，关联条件把温度与风机电流绑定，使报警具备“原因指向”——不是单纯说“热”，而是说“热且风机没转”，处置方向立刻明确。第三，恢复阈值低于报警阈值（27℃ 对 28℃），形成回差，防止温度在阈值附近反复穿越导致报警抖动。

再如氨气报警，可设两级：浓度 ≥ 20 ppm 持续 5 分钟为“预警”，≥ 25 ppm 持续 3 分钟为“严重”。等级不同，通知渠道和升级时限不同，这就是规则引擎与通知网关分工的价值。

四、通知网关的送达策略

通知网关的核心不是“发出去”，而是“确认被收到”。建议按等级配置通道组合：预警走 App 推送与微信，严重报警走短信加电话语音，并在规定时限内未确认时自动升级到上一级联系人。值班表按时间段轮换，避免夜间无人接收。所有通道的送达结果要落库，形成“谁在什么时间收到了哪条报警”的记录，这既是管理依据，也是故障复盘的数据来源。

五、架构落地时的常见取舍

小型养殖场可以先采用“边缘网关 + 云平台”的简化形态，把规则引擎与通知网关部署在同一台云服务器上，但逻辑上仍保持模块分离。随着舍栋数量增加，再把规则引擎独立出来，按舍栋分组做水平扩展。传感器数量多、上报频率高时，边缘层应做聚合上报，例如温度每 30 秒采一次、每 5 分钟汇总一次均值与极值上报，既降低带宽又保留趋势信息。

最后要提醒的是，架构设计必须为“报警之后”留出位置。用户终端的确认与处置反馈要回写到规则引擎，用于关闭事件、统计响应时长、标记误报。没有这条反馈回路，系统只能不断发通知，却无法判断异常是否真正被处理，也无法持续优化规则阈值。端到端架构的完整含义，正是从传感器一直闭环到人的处置动作。