3. 数据采集与边缘网关设计

养殖场的数据采集层面对的是一个“协议碎片化”的现实:环境控制器多用 Modbus RTU 走 RS485 总线,无线温湿度节点常用 LoRa 做远距离低功耗回传,舍内照明、门磁、部分传感器则可能采用 Zigbee 组网,而老式风机变频柜、水表电表往往只提供 RS485 接口。边缘网关的职责,就是把这些异构协议统一成一种上行数据格式,并在本地完成清洗、缓存与断网续传,使云端看到的是“一致的、可信的、不丢点的时间序列”。

一、多协议接入的物理与逻辑分层

接入设计要先分清物理层和协议层。RS485 是电气标准,Modbus RTU 是跑在它上面的应用协议,二者不能混为一谈;LoRa 是物理层调制技术,通常搭配 LoRaWAN 或私有协议;Zigbee 则是基于 IEEE 802.15.4 的组网协议。网关选型时必须确认它是否同时具备 RS485 收发器、LoRa 射频模块和 Zigbee 协调器能力,否则就需要多台设备或外挂模块。

以一座存栏 2000 头的育肥舍为例,典型接入清单可以是:3 台环境控制器(Modbus RTU,地址 1~3,波特率 9600,8N1)、12 个 LoRa 温湿度节点(上报周期 60 秒)、8 个 Zigbee 门磁与光照传感器、1 台 RS485 电表(Modbus RTU,地址 10)。网关需要为每类设备维护独立的采集任务:RS485 采用主站轮询,LoRa 采用接收上报,Zigbee 采用协调器入网后订阅。轮询周期要与设备响应能力匹配,例如环境控制器寄存器较多,可拆成两次读取,避免单次报文过长导致超时。

# 示例:Modbus RTU 轮询任务(伪配置)
device: env_ctrl_01
  port: /dev/ttyS1
  baud: 9600
  parity: none
  slave_id: 1
  polls:
    - name: temperature
      function: 0x03
      start: 0x0000
      count: 2
      interval_s: 10
    - name: fan_status
      function: 0x01
      start: 0x0010
      count: 8
      interval_s: 30

轮询失败要有明确的退避策略:单次超时重试 2 次,仍失败则标记该设备为“通信异常”,但不要阻塞其他设备的采集任务。这一点在多协议网关中尤其重要,因为一条 RS485 总线上的某个从站掉线,不应拖垮 LoRa 和 Zigbee 的接收线程。

养殖场多协议采集与边缘网关数据流 现场传感器与控制器 环境控制器 ×3 Modbus RTU / RS485 温湿度节点 ×12 LoRa 无线上报 门磁/光照 ×8 Zigbee 组网 电表 ×1 Modbus RTU / RS485 风机变频柜 RS485 只读 边缘网关 协议适配层:Modbus / LoRa / Zigbee / RS485 数据预处理:去重·量程校验·单位统一 本地缓存:环形队列 + 时间戳 断网续传:断点记录·补传·去重 上行封装:MQTT / JSON 主题发布 本地存储:eMMC / SD 卡(≥32GB) 云端监控平台 时序数据库 按设备+测点存储 告警与看板 阈值·趋势·报表 设备影子 在线状态·最后上报 补传数据校验 按时间戳去重 MQTT/TLS 断网时本地缓存

二、边缘网关硬件选型要点

网关不是“能跑 Linux 就行”,养殖场环境决定了几个硬指标。第一是接口数量与隔离:RS485 建议至少 2 路,且带 2500V 电气隔离,避免雷击或电机启停的共模干扰烧毁主控;LoRa 需外置天线接口,Zigbee 需确认协调器芯片型号与固件可升级。第二是存储:本地缓存要能撑住断网 72 小时,按 30 个测点、10 秒一个点估算,一天约 26 万条记录,72 小时约 78 万条,单条按 100 字节计约 78MB,因此 32GB eMMC 或工业级 SD 卡是合理下限。第三是供电与防护:舍内湿度高、氨气腐蚀性强,网关应选 IP54 以上外壳、宽温(-20℃~70℃)工业级产品,电源建议 12V 宽压输入并配防反接。

算力方面,若只做协议转换和缓存,四核 ARM Cortex-A53、1GB 内存足够;若要在网关侧跑轻量规则引擎(如温度超限本地联动风机),则建议 2GB 内存并预留 Python 运行环境。不要盲目追求高算力,养殖场网关的瓶颈通常在接口稳定性和长期无人值守的可靠性,而不是 CPU。

三、数据预处理与本地缓存策略

预处理在网关侧完成三件事:一是量程与合法性校验,例如温度寄存器原始值 0x7FFF 通常表示传感器故障,应丢弃并标记“无效”,而不是当成 327.67℃ 上传;二是单位与类型统一,把 Modbus 的整型放大 10 倍的原始值还原为浮点摄氏度,把 LoRa 节点的毫伏信号换算为百分比;三是去重与时间对齐,同一测点在轮询周期内重复读到相同值时可只保留变化点或按固定周期抽样,避免上行流量浪费。

本地缓存推荐“环形队列 + 落盘”的组合:内存中保留最近 1 小时数据用于快速补传,同时异步写入本地数据库(如 SQLite 或轻量时序库),每条记录带设备 ID、测点、采集时间戳、质量码。缓存要有容量上限和淘汰策略,例如按时间保留 7 天,超出后删除最旧数据,防止磁盘写满导致网关假死。

四、断网续传机制

断网续传的关键是“知道断在哪里、补到哪里、不重复”。网关应维护一个上行游标:每次成功发布后记录最后一条已确认数据的时间戳与序列号;网络恢复后,从游标之后按时间顺序批量补传,每批 200~500 条,收到云端确认再推进游标。云端按“设备 ID + 测点 + 时间戳”做幂等去重,即使网关重复补传也不会产生重复点。

判断续传是否成功的依据不是“网关显示已连接”,而是云端设备影子中的“最后上报时间”是否追平当前时间,以及补传批次确认数与本地待传数是否归零。建议在网关本地日志中记录每次断网起止时间、缓存条数、补传条数与失败重试次数,便于事后复盘。

实际部署时还要注意一个细节:断网期间本地联动不能停。温度超限触发风机、氨气超限触发报警,这些判断应在网关本地规则中完成,不能依赖云端下发。也就是说,边缘网关既是数据通道,也是本地控制的一道保险,这正是“边缘”二字在养殖场场景中的真正价值。