水利遥测终端怎么设计？从传感器采集、低功耗供电到4G/北斗通信

水利、水文和野外监测项目中的遥测终端，看起来像是一台“采集数据并上传平台”的设备，但真正进入研发阶段以后，往往同时涉及传感器接口、数据采集、电池与太阳能供电、低功耗、4G或NB-IoT通信、北斗备用链路、本地存储、远程配置以及户外可靠性等问题。

例如一个河道或水库监测站，现场可能同时存在水位计、流量计、雨量计、水质传感器等设备；而管网、边坡或其他无人值守场景，又可能增加低功耗、电池供电、振弦采集或者备用通信要求。

因此，水利遥测终端不能简单理解成：

传感器 + MCU + 4G模块。

更合理的研发思路，是先把采集对象、现场供电、通信条件和长期运行方式定义清楚，再决定主控板、接口、无线通信和软件架构。

一、水利遥测终端首先要解决的是“现场到底有什么数据”

在进入主控和通信方案之前，首先应该整理现场传感器清单。

不同水利项目的采集对象差异很大。水位、流量、水质、雨量、压力、土壤墒情等传感器，可能分别采用RS485、SDI-12、4–20mA、电压信号或者脉冲输出。

典型遥测终端需求中，甚至可能同时存在RS485、RS232、SDI-12、雨量脉冲、流量脉冲、模拟量、DI/DO以及继电器等多种接口。

因此项目启动阶段最好先形成一张设备接口表，而不是直接确定“需要开发一块RTU主板”。

这一步非常重要。

如果现场传感器型号和接口都没有确定，就提前固定主控板资源，很容易在后续阶段不断增加转接板、接口模块甚至重新改版PCB。

二、主控板应该围绕“采集、通信、供电”三个系统来规划

水利遥测终端的核心并不是某一种MCU，而是围绕现场数据形成稳定的采集和传输链路。

一个典型架构可以理解为：

水位 / 流量 / 雨量 / 水质等传感器

↓

RS485 / SDI-12 / 4–20mA / 脉冲 / DI

↓

接口保护与信号调理

↓

MCU主控 + 本地存储

↓

4G / NB-IoT / LoRa / 北斗等通信

↓

远程平台

与这条数据链并行的，是另外一套非常重要的系统：

太阳能 / 电池 / 外部直流供电 → 电源管理 → 主控、传感器和无线模块。

这也是水利遥测设备和普通室内控制板比较明显的区别。

现场设备经常需要长期无人值守，因此不仅要考虑“今天能否采到数据”，还要考虑断网、低电量、掉电、传感器异常以及数月甚至更长时间运行后的状态。

三、RS485、SDI-12和4–20mA为什么经常同时出现？

因为水利现场并不存在一种统一的传感器接口。

一些数字式水位、流量或水质传感器可以通过RS485通信；部分环境与水文传感器会采用SDI-12；压力、液位和工业传感器中又经常能够见到4–20mA输出。

所以一台通用遥测终端如果希望适配不同项目，通常需要在主控板资源和扩展接口上预留一定弹性。

但“接口越多越好”并不是正确方向。

每增加一种接口都会增加：

• PCB面积；

• 器件数量；

• 电源消耗；

• EMC风险；

• 固件复杂度；

• 测试工作量；

• 后续物料成本。

因此更合理的做法，是先分析哪些接口属于主要型号的共性需求，哪些更适合设计成扩展模块。

例如振弦采集就具有比较明显的专业性。种子需求中将振弦测量作为独立扩展子板，并面向大坝、边坡等监测场景，这种“主板保持通用、特殊采集独立扩展”的思路，比把所有功能全部堆在一块PCB上更利于产品系列化。

四、为什么水利遥测终端适合采用主控底板 + 功能扩展模块？

如果一款终端只有一个固定客户、固定接口和固定通信方式，完全可以针对这一型号设计一块专用PCB。

但很多遥测设备需要形成不同版本。

例如：

标准型需要较多采集接口和显示；

管网节点更关注低功耗和电池续航；

部分项目需要LoRa；

有些项目需要北斗备用通信；

地质监测项目还可能增加振弦采集。

如果每个版本从头设计一块主板，后续研发、BOM、固件和生产测试都会变得复杂。

因此可以考虑：

公共主控底板 + 可裁剪接口 + 独立通信/采集模块。

种子需求也采用了主控底板和扩展子板分离的产品思路，使接口、无线、显示等模块可以根据版本调整。

这种架构的真正价值不只是“方便插拔”。

更重要的是形成一个可复用的硬件平台：

主控、基础电源和公共通信保持相对稳定，不同项目只改变必要的采集或通信模块。

但模块化同样有代价，例如增加连接器、板间接口和结构空间，所以是否采用这种架构仍要结合预计型号数量和后续产品规划判断。

五、没有市电时，低功耗设计必须从整机工作周期开始

野外站点经常使用太阳能和蓄电池，地下管网等场景甚至可能长期依靠电池供电。

这时候最容易出现一个误区：

MCU休眠电流很低，所以设备一定能长时间运行。

实际上遥测终端的主要功耗很可能并不来自MCU。

传感器预热、4G联网、北斗通信、屏幕、电源转换以及外围电路的静态电流，都可能明显影响整机能耗。

因此真正应该先设计的是设备的工作周期：

深度休眠

→ 定时唤醒

→ 打开必要的传感器电源

→ 等待传感器稳定

→ 完成采集

→ 保存数据

→ 打开通信模块

→ 建网并上传

→ 关闭无线和外设

→ 返回休眠

对于部分实时性要求不高的站点，一天绝大部分时间都可能处于低功耗状态。

所以电源设计更适合按照不同功能域进行管理。例如把主控、传感器、通信和显示划分为不同电源域，让固件按照运行状态决定哪些模块需要供电，而不是让整个设备始终保持工作。

原始需求也明确提出将MCU、采集、无线和显示等划分为独立电源域，由软件按工作状态控制。

这种方法比单纯追求某一颗超低功耗芯片更有工程价值。北京心玥科技现有低功耗知识库也已经讨论过整机功耗预算、休眠、传感器和无线通信之间的关系，因此这篇方案不再重复基础原理，而重点落在野外遥测终端的工作周期设计上。

六、太阳能供电不能只按照“平均功耗”选电池和太阳能板

一个无人值守监测站点需要考虑的，不只是设备一天平均消耗多少电。

还要看：

• 连续阴雨天需要维持多久；

• 冬季或弱光条件；

• 电池温度特性；

• 通信模块启动峰值；

• 传感器同时供电时的瞬态功率；

• 电池允许的充放电范围；

• 太阳能控制器自身损耗。

因此，太阳能供电系统需要根据能量预算设计，而不能单独用“设备平均电流×24小时”得到一个数字后直接选择电池。

种子需求中同时考虑外部宽压输入、电池和太阳能输入，也说明真实遥测终端往往要兼容不同部署条件。

样机阶段最好通过实际工作周期测量整机电流曲线，再根据真实数据计算续航和太阳能配置，而不是完全依赖芯片手册中的典型功耗。

七、4G、NB-IoT、LoRa和北斗分别解决什么问题？

水利遥测终端可能同时出现多种无线方式，但它们解决的问题不同。

4G/Cat.1通常适合有公网覆盖、数据量相对较大或者需要较频繁交互的站点。

NB-IoT更适合部分低数据量、低频上报的场景，但是否采用还要结合当地网络覆盖、通信时延和业务要求判断。

LoRa更适合解决“多个附近节点如何先汇聚到一个站点”的问题。例如周围分布多个低速传感节点，可以由LoRa完成本地采集，再通过中心终端统一上传。

BLE通常不承担远程数据回传，而可以用于手机近距离配置、调试和维护。

北斗通信则具有另外一种价值。当监测区域没有稳定公网，或者项目要求设置独立备用链路时，可以根据实际业务和终端条件考虑卫星通信。

种子需求本身就同时考虑蜂窝、NB-IoT、LoRa、BLE和北斗等不同通信能力。

因此问题不应该变成：

4G和北斗哪一个更好？

而应该是：

现场有哪些网络条件？主链路是什么？备用链路是什么？每种链路分别传什么数据？

只有把这几个问题回答清楚，才能决定通信架构。

八、有4G和北斗双通道时，还必须设计软件切换逻辑

增加两种通信模块并不等于已经获得“双链路可靠性”。

真正需要定义的是：

正常情况下使用哪一路？

公网连续失败多少次以后切换？

切换到备用通道时是否发送全部历史数据？

网络恢复以后何时切回？

一条数据通过两路发送后，平台如何避免重复？

设备如何判断数据已经成功被服务器接收？

这些问题已经超出了纯硬件范围。

所以水利遥测终端如果需要蜂窝和北斗双通道，硬件需要确保两套通信链路可以独立供电和工作，固件还需要维护链路状态、发送队列、重试策略和数据序号。

如果设备进一步连接IoT管理平台，还需要继续考虑设备身份、在线状态、命令确认、离线缓存和恢复同步。北京心玥科技现有IoT知识库已经对这些平台机制进行了专门说明。物联网知识库

九、本地存储的重点不是“Flash有多大”，而是断网以后数据怎么办

遥测设备一般不会假设通信网络永远正常。

如果网络中断几个小时甚至几天，采集任务是否继续执行？数据存在哪里？网络恢复以后从哪里开始补传？

这些必须提前设计。

一种常见方式是：

采集数据 → 生成时间戳和序号 → 写入本地存储 → 尝试上传 → 服务器确认 → 更新本地发送状态。

断网以后继续积累待发送数据，连接恢复后按照策略补传。

这里并不能简单说：

“32MB Flash可以保存多少年。”

因为实际保存时间取决于：

通道数量 × 单次数据长度 × 采样周期 × 日志量 × 数据结构。

因此存储容量应该从数据量反推。

如果项目有长期历史数据要求，还需要提前确定哪些数据保存在终端，哪些只保存在服务器，以及本地数据满以后采用覆盖、压缩还是告警策略。

十、户外设备的可靠性设计，要围绕真实失效场景

水利遥测设备长期处在户外，面对的问题通常比室内控制器复杂。

线缆可能较长，外部传感器可能带入浪涌和静电，通信模块存在较大的瞬态电流，环境温度变化也会影响电池、电源和模拟采集。

因此方案阶段通常需要根据项目目标考虑：

接口ESD和浪涌保护、反接和过流保护、模拟与数字区域布局、通信接口保护、电源稳定性、看门狗以及无线模块异常恢复等。

原始需求中也把端口保护、PCB分区、独立看门狗以及无线模块独立复位作为可靠性设计内容。

但是必须区分：

按照某个防护目标设计

和

已经达到某个认证等级

是两件事。

例如IP防护等级还涉及整机结构、连接器、密封和实际测试；防爆场景更需要结合具体产品、使用环境和适用标准进行专门设计及认证。

不能因为PCB增加了保护器件，就宣称整机已经满足某个IP或防爆等级。

十一、样机阶段应该重点验证哪些内容？

水利遥测终端的第一版样机，不应该只在办公室连接几个模拟传感器跑通数据。

建议逐步进入真实运行条件。

首先验证每一种传感器接口，确认采集数据、供电以及异常检测正常；之后让多路传感器同时运行，检查模拟量稳定性和通信冲突。

无线通信部分需要验证弱网、掉线、重新建网和补传。

低功耗版本要记录完整电流曲线，而不是只测休眠电流。

太阳能或电池版本则应结合：

休眠 → 唤醒 → 采集 → 联网 → 上传 → 再休眠

测量完整工作周期的实际能量消耗。

此外还需要测试：

外部传感器掉线、通信模块卡死、突然断电、低电压、设备重启和长期运行等异常情况。

工业电子设备在样机阶段经常发生返工，本质原因之一就是接口、电源、通信和软硬件边界直到联调阶段才真正暴露。北京心玥科技现有样机返工专题对此有更完整的分析。

十二、开发水利遥测终端之前，客户需要准备哪些资料？

如果准备研发一款水利RTU或遥测终端，前期至少需要把下面几类信息梳理出来：

• 需要连接的传感器型号、接口和数量；

• 采样周期以及数据精度要求；

• 现场是否有市电；

• 电池或太阳能情况下的目标续航；

• 当地4G/NB-IoT网络覆盖情况；

• 是否需要北斗等备用通信；

• 是否存在LoRa子节点；

• 是否需要现场显示或手机配置；

• 断网后允许保存多少时间的数据；

• 是否需要远程参数配置、升级和设备管理；

• 安装位置、环境温度、防水及其他目标环境要求；

• 项目要求执行的行业标准、测试标准和验收条件。

如果其中部分信息暂时无法确认，也可以先通过系统方案阶段把接口、通信、供电和软件边界确定下来，再进入主控板和PCB设计。

这会比先做一块“接口尽可能多”的通用主板，再根据现场问题不断修改，更容易控制研发风险。

十三、水利遥测终端本质上是一个软硬件协同系统

一套真正能够长期运行的遥测终端，不只是硬件采集板。

从完整系统来看，它通常涉及：

传感器接口 → 主控板 → 嵌入式固件 → 本地存储 → 无线通信 → 服务端接口 → 设备管理和数据展示。

不同项目可以只开发其中一部分，也可以按照完整系统实施。

北京心玥科技可围绕水利遥测、野外数据采集及类似工业监测终端需求，开展主控板与采集接口设计、嵌入式固件、4G/LoRa等通信接入、PCB/PCBA样机和设备联调；如果项目还需要上位机、Web后台或IoT设备管理系统，也可以根据实际需求进行配套开发。

真正需要在项目开始时确定的，并不是“使用哪一颗MCU”，而是：

现场需要采什么、多久采一次、靠什么供电、数据怎么传，以及通信失败以后设备应该继续做什么。

这些问题确定以后，才有条件设计一台真正适合现场长期运行的遥测终端。