4G/5G 物联网在智慧水利中的应用：小型水库雨水情测报与大坝安全监测组网实践
4G/5G 物联网在智慧水利中的应用，是指用蜂窝网络替代人工报送与有线专线，把分散在山区的小型水库雨水情测报站、大坝安全监测站接入统一平台，实现水位、雨量、渗压、位移等要素的分钟级自动采集、断网续传与远程运维。其核心在于"4G CAT.1 为主 + VPDN 专网卡 + 流量池共享 + 机卡绑定"这套组合：把过去"一天一报、故障靠人上山找"，改成"5 分钟一报、故障平台先知道"。
小型水库是防汛体系里最不起眼、也最容易出事的一环。它们大多建在山沟里，库容不大，一旦漫坝，下游往往就是村镇。而现实是：不少小型水库的雨水情数据，今天还靠巡查员每天早上八点打电话报一次。
这篇文章讲一个真实组网项目怎么落地——包括被否掉的两个方案，和施工阶段踩进去的三个坑。
小型水库雨水情测报的三个现实约束
约束一：点位散在山区，有线网络到不了
一个县动辄几十上百座小型水库，分布在不同山坳河谷。拉光纤要沿山开路、立杆、跨沟，单站造价常高于整套监测设备，汛期一断就是几天。通信只能是无线的，且必须"通电即联网"。
约束二：供电靠太阳能，功耗比带宽更值钱
绝大多数测报站没有市电，靠 18V/30W 单晶硅板配 12V 蓄电池，连续阴雨三五天就见底。终端必须深度休眠，制式也不能一味追速率——速率越高、射频前端越复杂，功耗通常越大。用 5G 传几个字节的水位数据，是典型的用错工具。
约束三：数据要上报，但不能"裸奔"在公网上
水位、库容、渗压直接关系防汛调度。走公网、走动态 IP，一旦被扫描仿冒，后果不好收拾。水利项目普遍要求数据不出专网、限制访问源 IP、支持点对点或点对多点组网。这就是 VPDN 专网卡存在的理由，也是初次做水利项目的集成商最容易漏掉的一环。
一个雨水情测报站由什么组成
先把设备清单摆清楚，后面谈选型才有落点。
| 部分 | 典型设备 | 选型与实施要点 |
|---|---|---|
| 水情采集 | 雷达式 / 压力式 / 浮子式水位计 | 山区河道多泥沙，非接触的雷达式省维护 |
| 雨情采集 | 翻斗式雨量计 | 需定期清淤防堵，分辨率常见 0.2mm 或 0.5mm |
| 数据采集 | 遥测终端机（RTU） | 支持多路 RS485/模拟量，本地存储不少于 7 天 |
| 通信单元 | 4G 遥测终端（内置 CAT.1 模组）+ 物联网卡 + 天线 | 模组与卡需匹配，天线必须外置架高 |
| 供电单元 | 18V/30W 太阳能板 + 12V 蓄电池 + 控制器 | 按连续阴雨 7 天备电设计，低温区注意容量衰减 |
| 防护 | IP66 机箱、防雷接地、防盗抱箍 | 山区雷暴多，接地电阻与浪涌保护是硬要求 |
系统分四层：感知层（水位计、雨量计、渗压计、位移计、可选视频）→ 网络层（4G 遥测终端 + 物联网卡 + 天线）→ 平台层（SAAS 物联网卡管理平台 + 水利业务平台）→ 应用层（县级预警系统、省市平台对接、值班 APP）。
四层里最容易出问题的永远是网络层。 感知层坏了是单站失明，网络层配错了是整片失联。
组网方案与选型：为什么主推 4G CAT.1
卡种怎么配：一张表看清取舍
同一项目里，不同点位的卡不该是同一个型号。
| 方案 | 适用场景 | 优势 | 局限 | 本项目取舍 |
|---|---|---|---|---|
| 公网 4G 卡（CAT.1） | 一般雨水情、墒情站点 | 开通快、资源足、资费低 | 数据走公网，需平台侧加固 | 基础方案，与专网 APN 叠加 |
| VPDN 专网卡 | 数据敏感、需限定访问 IP、点对点/点对多点 | 数据不出专网、可做 IP 白名单 | 需报备联调，开通周期略长 | 主方案，全部站点纳入水利专网 |
| 定向流量卡 | 只访问固定平台、成本敏感 | 资费更低、防漫游滥用 | 目标地址变更需重配 | 备选，用于纯上报站 |
| NB-IoT 卡 | 极低频、纯电池供电 | 功耗低、穿透强 | 时延高、不支持切换、无法加测 | 未采用 |
| 5G 卡 | 视频、图像、大带宽 | 带宽大、时延低 | 功耗与成本高，山区覆盖不足 | 3 站作为可选配置 |
最终 186 座水库分配为：183 站单网 CAT.1（VPDN 专网）+ 3 站 CAT.4（带图片回传）。
其中 6 个跨省界、处在弱覆盖区的站点没有单独设一档，而是在勘察阶段逐站实测 RSRP/SINR，按当地覆盖最优的运营商单独配卡——三个县区相邻，各家的覆盖强弱并不一致，逐站选网比统一发卡更可靠，也不增加成本。
不选 NB-IoT 的三个硬伤：不支持连接态切换，山区漂移易掉线；时延偏高，"加测"指令响应慢；后续加图片链路不够用。不选 5G 更简单：山区覆盖不连续，终端在 5G/4G 间反复重选，功耗和掉线率反而上升。
这里也是本项目坚持走 VPDN 专网卡（4G/5G 互通卡）的原因：该专网卡方案效果等同光纤专网，但价格只有后者的 1/2 甚至更少，且无需布线、即插即用——这正是 186 个山区站点能在汛前完成联调的关键。
流量怎么算：单站每月 8MB 的来路
很多项目在报价阶段被流量成本卡住，本质是没算过账。按汛期 5 分钟一报测算：
| 流量项 | 频次 | 单次报文 | 月流量估算 |
|---|---|---|---|
| 水位/雨量定时上报 | 288 次/日 | 约 0.6 KB | 约 5.2 MB |
| 链路心跳保活 | 48 次/日 | 约 0.2 KB | 约 0.3 MB |
| 平台指令与参数回读 | 约 300 次/月 | 约 0.6 KB | 约 0.2 MB |
| 断网缓存补传（偶发） | 按 10% 冗余 | — | 约 0.6 MB |
| 协议开销与重连 | — | — | 约 1.2 MB |
| 合计（设计值） | — | — | 约 7.5–8 MB/月 |
结论直接：纯上报站点一个月连 10MB 都用不到，却常被按 100MB 甚至 1GB 的套餐采购。 几百张卡凑在一个共享池里按总量结算，才是把资费降下来的正路。带图片回传的 3 个站单站月均约 260MB，另设小池，避免拖累整体。
省电与远程唤醒：一对必须调和的矛盾
为了省电，很多项目把终端设成深度休眠，几十分钟甚至一小时唤醒一次。省电是省了，但汛期要临时加测一次，指令发下去得等一小时，值班员不会接受。
本项目做法：PSM 周期压到与平台心跳对齐（5 分钟），只上报变化量与定时帧，同时保留独立唤醒通道。卡侧配合优化唤醒策略后，实测下发指令到响应平均 18 秒，满足"半分钟内远程唤醒"。省电靠的是少发、短帧、空窗设计，不是靠"睡得久"。
案例复盘：某省某市三县区 186 座小型水库雨水情测报设施建设
以下数据经脱敏处理，仅保留量级与逻辑，客户名称与具体行政区划不予披露。
项目背景与时间线
项目位于某省某市，下辖 A、B、C 三个县区，186 座小型水库需建设雨水情测报设施，其中 42 座同步接入大坝安全监测（渗压、位移）。
2024 年 12 月：逐站勘察，记录信号强度、遮挡、供电条件；
2025 年 3 月：设备进场，三个施工队同步推进；
2025 年 5 月 28 日：186 站全部联调上线，赶在主汛期前完成；
2025 年 6—8 月：经历 3 轮连续强降雨，其中 1 轮单日大暴雨。
选在汛前完工是这类项目最硬的约束——设备没上线，汛期就是纯风险敞口。
改造前的四个具体问题
报送频次低：人工每日 1 次，早 8 点电话或微信上报，夜间降雨过程完全空白。
数据不可追溯：口头报送加纸质台账，缺报漏报事后无从查证，考核时说不清。
卡与资费分散：三个县各自采购不同运营商的卡，套餐档位不一，台账在三个人手里，对账靠手工合并 Excel。
故障发现靠人：设备停摆要等巡查员下次上山或群众反映，平均处置周期约 2 天。
选型过程：两个方案被否掉
第一轮，全部用 NB-IoT。 否：不支持切换、山区易掉线；加测响应慢，不满足汛期调度；后续加图片无扩展空间。
第二轮，全部上 5G。 否：山区覆盖不连续，终端反复重选；186 站规模下成本不划算。
第三轮，CAT.1 为主、按点位分流。 定型 183 站单网 CAT.1 + 3 站 CAT.4，跨省界与弱覆盖点位逐站实测信号后确定运营商，全部纳入 VPDN 专网，开启机卡绑定，流量统一进共享池。
踩过的三个坑
坑一：天线装进了机箱里。 第一批 40 个站，施工队图省事把吸盘天线贴在镀锌机箱内壁。联调时 RSRP 普遍在 -105 至 -118 dBm，11 个站频繁掉线。处理：机箱开孔加 N 型接头，天线外置架高至 1.5 米以上并朝基站方向，弱覆盖站换高增益定向天线。处理后 RSRP 回到 -85 至 -95 dBm，掉线归零。金属机箱就是个法拉第笼，天线必须出箱。
坑二：休眠周期设太长，远程唤醒形同虚设。 为省电，初版固件把 PSM 周期设成 60 分钟，平台下发加测要等一小时，值班员直接在群里投诉"发了没用"。处理：周期压到 5 分钟与心跳对齐，上报只发变化量，打通独立唤醒通道。改完平均 18 秒响应，续航仍在设计范围内（连续阴雨 7 天不欠压）。
坑三：机卡绑定之后，卡装错了站。 施工期两张卡装反位置，绑定生效后无法上线，现场第一反应是"信号不好"，白跑两趟山路。处理：建"一站一码一卡"台账，每张卡贴点位二维码；平台侧开放批量解绑/绑定，换卡 10 分钟内完成；开启"最后在线时间"看板，超 2 小时未上报自动进待核查列表。
量化结果
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 数据报送频次 | 人工 1 次/日 | 汛期 5 分钟/次，非汛期 15 分钟/次 |
| 数据到报率 | 约 85% | 99.2%（2025 主汛期统计） |
| 单站月均流量 | 按 100MB 套餐采购，实耗约 6MB | 实耗约 8MB，纳入共享流量池 |
| 单卡月均资费 | 基准 100 | 下降约 30% |
| 故障平均处置时长 | 约 2 天 | 约 4 小时 |
| 汛期人工巡检频次 | 每站每月 4 次 | 每站每月 1 次 |
| 跨县站点调度 | 换卡、换套餐 | 平台改地域，当天生效 |
到报率从 85% 提到 99.2%，靠的不是设备变好，而是三件事同时做了：天线出箱、断网补传、平台侧停机告警。
弱覆盖、断网与故障处置：现场经验清单
RSRP 分档处置：优于 -95 dBm 为良好；-95 至 -105 dBm 可用但需优化天线位置；-105 至 -115 dBm 属弱覆盖，必须外置高增益定向天线；低于 -115 dBm 评估中继或换运营商。
断网缓存续传：RTU 本地至少存 7 天原始数据，恢复后按时间戳补传，平台侧去重。山区雷雨、基站退服是常态，没有续传等于数据必丢。
雷击与接地：太阳能支架、机箱、馈线做等电位接地，馈线加浪涌保护器。汛期雷击损坏占硬件故障一半以上。
欠压降频而非关机：电压低于阈值时先把上报间隔从 5 分钟拉到 30 分钟，保住"活着"，不要直接断电失联。
平台侧三道告警：卡停机、超时未上报、流量异常（突增/归零）。前两个管失联，第三个管被盗用。
结语
这件事技术难度并不高，难的是在山区、无市电、弱覆盖、汛期不能停的条件下，让 186 个点同时在线。答案不是更贵的设备，而是几件朴素的事做扎实：天线出箱、专网隔离、流量进池、断网能补、故障平台先知道。
FIFISIM物联（北京智德传技术有限公司）在这类项目里提供的，就是"卡 + 模组 + 平台 + 工程师"这一条链路的确定性。
