3. 监控系统总体架构设计

智慧水产养殖监控系统看似由一堆传感器、摄像头、增氧机和手机App拼装而成，但真正决定系统能否长期稳定运行的，是它背后的分层架构。把系统划分为感知层、传输层、平台层、应用层，本质上是在回答四个问题：现场有什么数据要采？数据怎么可靠地送出来？数据在哪里被存储、清洗和判断？最终由谁、以什么方式使用这些判断结果？四层各司其职，接口清晰，才能做到某一层出问题时快速定位，而不是"整个系统一起坏"。

四层的职责边界

感知层是系统的"感官"，直接与养殖水体、空气、设备和生物接触。典型对象包括溶解氧探头、pH电极、水温传感器、氨氮/亚硝酸盐在线分析仪、液位开关、电表与电流互感器、增氧机运行状态反馈、投饵机料位、以及水下或岸基摄像头。感知层的核心指标不是"传感器多"，而是测量点位的代表性与信号的可信度。例如池塘溶解氧探头若固定放在增氧机正下方，测到的永远是局部高值，无法反映鱼类实际活动区；合理做法是分层布点（表层0.3～0.5 m、中层、底层），并在投饵区与深水区各设一点。感知层输出的是标准信号：4～20 mA、0～10 V、RS-485（Modbus-RTU）、或开关量干接点。

传输层解决"从塘口到机房/云"的链路问题。近距离（同一厂区、单个池塘群）常用RS-485总线、以太网、LoRa；跨距离、无市电、无网线的塘口则依赖4G/5G、NB-IoT。传输层设计的关键是供电与通信的冗余：太阳能+蓄电池保证阴雨天续航，4G主链路配一条备用SIM卡或LoRa回传，避免"断网即失控"。同时要明确采集周期与上报策略——溶解氧可1～5 min一采，水温可5～10 min一采，视频按需拉流，避免流量与功耗失控。

平台层是系统的"大脑与账本"，承担设备接入、协议解析、数据存储、规则引擎、告警计算与联动控制。它把不同厂家、不同协议的设备统一成标准数据模型（设备ID、测点、时间戳、质量码），并保存历史数据供追溯。规则引擎负责把"原始数值"翻译成"业务判断"，例如"溶解氧低于4 mg/L持续5 min → 触发一级告警 → 启动增氧机"。平台层还要处理数据质量：超量程、长时间不变、跳变、离线等异常标记，避免把坏数据当成真实现象去联动。

应用层面向人，提供Web监控大屏、手机App、微信/短信告警、报表与养殖档案。应用层不直接碰硬件，它只消费平台层提供的标准接口。这样换一套App或增加一个第三方监管对接，都不需要动底层设备。

为什么必须分层，而不是"一锅端"

很多早期项目把采集、判断、控制全塞进一台现场控制器，短期能跑，但一旦要增加一个塘口、换一种传感器、或对接监管平台，就要大改。分层之后，接口成为契约：感知层只要保证输出标准信号，传输层只要保证链路通，平台层只要保证数据模型稳定，应用层就能独立迭代。排障时也清晰——App上看不到数据，先看平台有没有收到（平台层），再看网关是否在线（传输层），最后查探头供电与信号（感知层），逐层收敛，而不是盲目换设备。

场景选型的判断依据

选型不是选"最先进"，而是选与现场约束匹配的方案。可以从四个维度判断：供电条件（有无市电、能否铺太阳能）、通信条件（有无宽带、4G信号强度）、控制实时性（断网时是否必须本地动作）、测点密度（单塘几个点还是单池十几个点）。

以池塘为例，一个10亩塘、无市电、4G信号两格的现场，合理配置是：塘边立一根太阳能杆，装一台低功耗边缘网关（内置LoRa接收与4G模组），塘内布2～3个DO测点（表层与底层各一，投饵区一个），网关本地保存最近7天数据并执行"DO低于4 mg/L持续5 min启动增氧机"的规则，即使4G中断，增氧机仍能按本地规则动作；网络恢复后补传缓存数据。这套配置的取舍是：牺牲了视频实时性（按需拉流），换来了供电自洽与控制自治。

工厂化循环水则相反：有市电、有厂区网络、控制实时性要求高（水泵停转几分钟就可能缺氧），因此应以有线为主、PLC为执行核心、平台做监视与记录。此时把联动逻辑放在PLC里，平台层负责采集PLC状态、生成曲线与告警，避免"云上判断、网断失控"。网箱场景的核心矛盾是维护成本，应优先低功耗、耐腐蚀、少维护，上报周期可放宽到5～10 min，视频采用事件触发而非常开。

一个可执行的选型对照

需要强调的是，表中的周期与配置属于教学示例，实际项目要结合探头响应时间、流量资费和运维人力调整。例如光学DO探头响应较慢，上报周期设得过密只会增加流量而不增加信息量；而工厂化池体小、水体交换快，30 s级的上报才足以捕捉溶氧骤降。架构设计的价值，正在于把这些"看起来是参数"的选择，放回到分层职责里说清楚：谁负责采、谁负责传、谁负责判、谁负责用。