前置资料：文中用到的选型对比表（Excel 可编辑版）和大坝廊道组网方案模板，已打包放在网盘：夸克网盘下载（提取码 dzLd）。
一、从一次"数据失联"说起
做监测的人多少都经历过这种场面：平台上看某个测值，曲线齐刷刷停在了三天前。打电话问现场，供电正常、传感器正常，问题出在最不起眼的一环------数据出不来。
我撞见过最典型的一次是在一个抽水蓄能电站项目上：下水库大坝的灌浆廊道里装了一批渗压计和静力水准仪，实施时图省事直接给采集站配了 4G DTU。结果廊道深入坝体几十米，人一进去手机信号就归零，设备也一样------数据断了整整一天，最后是拿着笔记本电脑走到廊道口手动拷数据，才把曲线接上。
这件事之后我养成了一个习惯：方案阶段先做通信设计，而不是等设备到场再想办法。这篇文章把自动化监测里常用的几类通信技术捋一遍，横向对比适用场景，最后给大坝、抽蓄这类廊道环境一套可以直接抄的组网思路。
二、先算需求：通信要扛住什么
选型之前先把账算清楚，很多方案不是败在技术不行，而是败在没算账。
数据量：以一条典型监测线为例，40 台传感器、5 分钟一条、单条报文按 120 字节算，一天约 1.4MB------就算翻十倍也才十几 MB。变形监测的数据量对带宽几乎不敏感，真正敏感的是"每天都要能通"。要单独留余量的是现场摄像头抓拍和突发告警后的批量补传。
实时性：预警要求多久送达？常规变形监测分钟级足够，滑坡应急、渗流异常可能要求秒级推送------这直接决定了能不能用"定时唤醒 + 批量上传"的低功耗方案。
可靠性：汛期恰恰是数据最不能断的时候。主链路之外要不要留备用链路，预算阶段就得定下来，不能等出了事再补。
供电：廊道里有没有市电、野外点位能不能布太阳能板，直接决定那些"耗电大户"能不能进候选名单。
这四笔账算完，候选技术基本已经筛掉一半。
三、有线阵营：RS485 和光纤
RS485 是变形监测行业事实上的默认选项：Modbus RTU 协议、双绞屏蔽线、手拉手总线，一条总线理论传输 1200 米、稳定挂载 32 台设备，加中继器还能继续扩展。成本极低，静力水准仪、固定式测斜仪、渗压计这类主流设备出厂就带 RS485 接口，接入几乎零门槛。
坑也集中在它身上：和强电桥架一起走线容易引入共模干扰；山区雷雨季浪涌顺着总线打设备，防雷器和信号隔离模块的钱不能省；多台设备共地不良时通信偶发丢包，排查起来非常熬人。
光纤是有线的天花板：单模轻松跑 10 公里以上，完全免疫电磁干扰，雷暴天照传不误。代价在施工------要熔接、要穿管保护，廊道段还要防潮，单公里造价明显高于 RS485。但对于长坝、抽蓄电站输水系统廊道这种"一次建成几十年不动"的场景，光纤值得投入。
至于 M-Bus、CAN 总线，监测行业见得不多，了解即可。
四、无线公网：4G Cat.1 和物联网卡
2G 退网之后，4G Cat.1 成了物联网公网的绝对主力：时延秒级、速率对监测报文绰绰有余、模组只要几十块钱，跑 MQTT 或 TCP 透传毫无压力。5G 和 Cat.4 留给视频监控、无人机巡查这类吃带宽的场景。
公网方案绕不开物联网卡：普通卡需要实名，定向流量卡便宜但只能访问指定服务器。更常见的坑是卡被限速或"停机保号"------物联网卡有独立管理平台，项目里要约定流量阈值告警，别等数据断了才发现是卡欠费。
廊道环境的死结在于：坝体深处没有公网信号。常规解法是把采集终端放到廊道口或坝顶机房，廊道内用 RS485/光纤把数据引出来。天线确实要伸进廊道时记住一条经验：馈线每多十米就多一分损耗，超过 30 米基本该考虑光纤中继了。
五、低功耗广域与卫星：LoRa、NB-IoT、北斗短报文
LoRa 是自建网的代表：470MHz 免许可频段、睡眠电流微安级、两节电池能撑数年，坝顶架一个网关就能覆盖方圆三五公里，特别适合库岸、边坡上没有市电的分散测点。代价是网络要自己建自己维护，而且 470MHz 功率受限，山区遮挡多的工点必须实测覆盖。
NB-IoT 是运营商建的网，不用自己维护基站，资费一年几十块。但它依赖运营商信号覆盖，深廊道、涵洞里照样没戏，更适合城镇周边的分散小型测点。
北斗短报文是最后防线：不依赖地面公网，地震、洪涝把基站全打断的时候，它还能把关键告警发出来。民用区域短报文单次可发千余汉字，但有发送频度限制，终端和通信费按"条"计价，成本是 4G 的几十倍。常规用法是当备份链路：平时休眠，主链路中断超过阈值才启用，只传告警和关键测值。天通、海事卫星思路类似，按工点所在区域的覆盖选。
六、选型对比表
把上面几类技术放进同一张表：
| 技术 | 距离/覆盖 | 速率 | 功耗 | 单点成本 | 施工难度 | 典型场景 |
|---|---|---|---|---|---|---|
| RS485 | 1200m/总线 | kbps 级 | 极低 | 极低 | 低 | 廊道/隧洞内传感器接入 |
| 光纤 | 10km+ | 高 | 无 | 中（含熔接） | 高 | 长距离干线、强电磁环境 |
| 4G Cat.1 | 运营商覆盖 | Mbps 级 | 中 | 低 | 低 | 有公网信号的主力上云链路 |
| NB-IoT | 运营商覆盖 | kbps 级 | 极低 | 极低 | 极低 | 分散小数据测点 |
| LoRa | 3~5km 自建 | kbps 级 | 极低 | 中（含网关） | 中 | 无市电分散测点汇聚 |
| ZigBee | 数百米/跳 | kbps 级 | 低 | 低 | 中 | 隧洞、廊道内中继接力 |
| 北斗短报文 | 全国覆盖 | 极低 | 中 | 高 | 低 | 无公网区应急备份 |
顺手记下我见过的五个高频坑：
- 沿用 2G 老设备忘了退网时间表，一夜之间 DTU 集体失联；
- 馈线贪长，天线明明架在坝顶，损耗把信号吃得干干净净；
- 物联网卡欠费、限速没人盯，数据断了先怀疑设备硬件；
- RS485 不做防雷隔离，一场雷雨报废半条总线；
- 低功耗设备设成"永不离线"，太阳能板冬天亏电，先趴窝的反而是它。
七、大坝/抽蓄廊道的推荐组网
把结论拼起来，就是一套可以直接抄的架构：
廊道内：传感器 RS485 手拉手接入采集站，超过 1200 米或强干扰段改光纤；采集站必须做本地缓存（SD 卡至少存 7 天数据），链路断了数据不丢。
廊道口/坝顶机房：做汇聚。主链路 4G Cat.1 跑 MQTT 上云，有条件的项目再熔一条光纤专网做双保险；北斗短报文终端做应急备份，只发告警。
协议上：云侧常见 MQTT/TCP 透传，水利口项目按业主要求可能要对接 SL651 水文规约或 HJ212，选网关时确认支持情况。
供电上 ：廊道内取市电配 UPS，坝顶设备太阳能加锂电池。
八、写在最后
通信选型没有"最强技术"，只有"最合身的方案"：先算清需求四笔账，再对着对比表逐栏淘汰，最后拿真设备去现场最差的点位实测------纸面参数和现场表现，永远是两回事。
文中用到的选型对比表（Excel 可编辑版）和大坝廊道组网方案模板已打包上传：夸克网盘点此下载，提取码 dzLd。