水利遥测终端怎么设计？从传感器采集、低功耗供电到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风险；

• 固件复杂度；

• 测试工作量；

• 后续物料成本。

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

例如，大坝、边坡等监测场景可能需要振弦式传感器采集，其测量电路和信号处理方式与常规数字接口存在差异。如果终端需要兼容多种采集功能，可以考虑将振弦采集设计为独立扩展模块，让主控板保留通用的数据处理和通信能力。这种方式有利于不同型号复用主控平台，但也需要综合评估扩展接口、结构空间和成本。

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

如果一款终端的接口、通信方式和使用条件已经明确，且后续不需要扩展多个型号，可以优先评估集成式专用主板方案。

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

例如：

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

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

部分项目需要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”，而是：

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

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