企业官网建设流程全解析

干内涝监测这行快十年了，我手机里最怕存的一个号码就是汛期值班室。暴雨预警一发，值班电话就响个不停，但那些电话里问得最多的不是“雨多大”，而是“积水多深了”。前些年很多城市布设的还是立杆式积水监测站，一到暴雨天就状况百出——立杆被撞歪、传感器被冲走、垃圾裹住水位计，甚至还有设备正对着排水口，水退得比数据快，平台端满屏的红点，根本没法用。这也是为什么最近两年，地埋式积水监测站逐渐成了城市内涝监测设施升级的主流选择。

地埋式积水监测站，简单讲就是整套设备嵌进路面铺装层里，外壳和路面齐平，车辆正常碾过也没事。传感器直接接触路面汇集的积水，实时采集水深数据，再通过窄带物联网把数据传回监测平台。它不占地上的空间，不破坏城市景观，也不用担心“立杆式”那种被人为损坏或遮挡的问题。这篇文章我把这套设备从选型、硬件组成、供电设计、数据上报逻辑、施工安装到后期运维，完整地拆开讲一遍，适合负责城市排水管理、做内涝监测项目集成、或者正在为小区、下穿隧道、地下车库选型监测设备的工程师和管理人员参考。

1. 为什么内涝监测需要“地埋式”：选型背后的真实痛点

1.1 立杆式设备在城市里的生存难题

我实地走访过不少内涝易发点，大多数点位不是没装设备，而是立杆式设备活不长。一个立杆式积水站通常由一根四五米高的立杆、横臂、太阳能板和超声波/雷达水位计组成。这套东西装在路边，问题接踵而至：市政绿化修剪时被碰，工程车辆倒车直接撞歪，也有人觉得杆子挡路把线剪了。更麻烦的是，超声波水位计安装在立杆上方，需要向下发射波束测量积水深度，一旦风向不对、水体波动剧烈，回波质量就很差；有杂物漂过时更是直接丢数据。

而且从城市规划角度来看，城市道路空间非常紧张。一个立杆要占人行道或绿化带的位置，涉及多个部门协调。我在一个老城区改造项目中就遇到过，设备点位已经定好了，结果现场施工时交管部门不同意杆子立在那，最后只能改位置，导致监测覆盖半径出现缺口。地埋式积水监测站把设备做成一个和路面齐平的“井盖式”结构，嵌入路面后不细看都不知道这是个监测设备，协调成本明显低一截。

1.2 三种主流积水监测方案的真实对比

抛开单一方案盲目推广的说法，我把实际接触过的主流积水监测形式放在一起对比一下，各有各的适用场景：

地埋式方案最大的优势是“传感器就在积水环境里”，它测的不是某个悬挂高度换算出来的距离，而是真正作用在路面上的水体静压，对有落叶、油污、漂浮物的城市雨水更有适应性。尤其是下穿隧道、地下车库入口、桥涵这种车流密集又容易积水的点，立杆式安装条件往往不具备，地埋式成了唯一可行的选择。

2. 地埋式积水监测站的硬件核心：传感器、主控与通信链路

2.1 水位测量原理：为什么静压式比超声波更适配地埋

地埋式积水监测站普遍采用静压式水位传感器，也叫投入式压力液位计。它的工作基础是流体静力学：水深 h 与传感器感受到的压力 P 的关系为 P = ρgh，其中 ρ 是水的密度，g 是重力加速度。传感器内部的压阻式芯体把水压转换为电信号，经过放大和模数转换后，主控单元就能换算出当前积水深度。

这个原理听起来简单，但实际接线时有个容易被忽略的坑：大气压补偿。静压式传感器膜片的一面接触水体，另一面必须通过导气管接通大气，否则大气压变化会直接叠加到水压上，导致水位读数漂移。地埋式设备在结构设计上需要预留导气通道，并且要防止水汽进入导气管。我见过一个项目换了好几支传感器，读数始终偏高，拆开才发现设备在安装时导气管被密封胶堵死了，里面形成了一个封闭气室，等于一直在测“水体压力+气室负压”，数据自然不准。

超声波方案在地埋式设备上应用较少。地埋式设备的安装空间在地下井内，高度有限，超声波换能器向下发射信号的距离太短，盲区占掉大半量程；而且水面漂浮物对超声波回波衰减严重，容易误判。所以在地埋式的结构里，静压式是目前最稳的选择。

2.2 主控单元与采集策略：低功耗MCU的选型和滤波逻辑

地埋式设备的主控单元不需要很强的算力，关键在于低功耗、稳定、接口丰富。目前主流的方案是选用一颗ARM Cortex-M3或M4内核的低功耗MCU，比如STM32L系列，运行频率控制在几十兆赫兹，待机模式下电流可以做到微安级别。

数据采集不是简简单单每隔几秒读一次传感器就算完事。路面积水场景中，车辆碾过传感器上方会产生瞬时水压冲击，如果直接采原始值上报，会出现一个很突兀的尖峰，平台端看起来就像水位突然跳变。通常的做法是在设备端做“滑动平均滤波”——连续采集10次，每次间隔200毫秒，去掉最大值和最小值，对剩余8个值取平均，作为本次有效水位。这个处理让数据曲线平滑得多，也避免误报。

我在调试时曾经发现过一个有趣的现象：两个相邻监测站数据差异非常大，排查后发现其中一台设备的传感器安装位置距离路面泄水口太近，车辆快速通过时带起的水浪直接拍在传感器膜片上，瞬时压力可以高出真实水位十几厘米。后来除了在算法上加强滤波，物理上也调整了传感器位置，让它避开直冲水流。

2.3 通信模块选型：NB-IoT是首选，4G Cat.1什么时候用

地埋式设备的通信模块，我目前最推荐NB-IoT窄带物联网。原因有三：一是工作频段低，对于安装在路面以下、信号需要从地面穿透到井内的场景有更好的覆盖能力；二是本身面向低功耗、小数据量的物联网场景设计，单次上行功耗低；三是运营商网络覆盖广，在城市地下空间、隧道、地下室等场景普遍有信号部署。

4G Cat.1适合需要更高实时性和大带宽的场景，比如监测点需要同时回传现场图片、视频或语音喊话时，Cat.1的优势才会体现出来。但代价是平均工作电流在100毫安以上，对电池供电的设备压力较大。如果项目点位有条件提供市电，或者现场有路灯接口可以取电，那选Cat.1也未尝不可。

如果涉及园区、隧道群这类范围有限的场景，也可以考虑LoRa自组网方案。设备端功耗低，但需要现场部署网关，网关再通过4G或光纤和平台通信。整体上，LoRa方案适合点位集中、产权明确的单位用户（比如一个大型园区内部），而覆盖城市级的监测网络还是NB-IoT更省心。

3. 供电与低功耗设计：地埋式设备真正难啃的骨头

3.1 纯电池供电方案的可行性计算

地埋式设备不像立杆式那样能挂一块太阳能板，它的电只能来自“一次性锂亚电池组”或者“市电/路灯取电”。大部分城市道路点位不具备取电条件，所以纯电池供电是常态。

以常用的锂亚硫酰氯电池ER34615为例，单节容量约19Ah，设备内装两节并联，总容量约38Ah。锂亚电池的特点是能量密度高、自放电率低（年自放电小于2%），非常适合长时间小电流放电场景，但瞬间大电流输出能力弱，所以通常还要并联一个超级电容组，用于通信模块发射时的瞬态供电。

来做一道简单的功耗估算：

• 待机电流：MCU处于低功耗模式约5μA，传感器通过模拟开关控制周期性供电、平均约10μA，再加上RTC和其他损耗，整机待机电流控制在15μA以内；
• 通信电流：NB-IoT模块单次上报平均电流约160mA，持续时间按3秒计算；
• 上报频率：正常工况每小时上报1次，汛期按阈值加密，暂按每天24次再加10次加密上报计算；
• 单次上报消耗电量：160mA * 3s = 480mAs ≈ 0.133mAh；
• 全年上报消耗电量：0.133mAh/次 * 34次/天 * 365天 ≈ 1.65Ah；
• 全年待机消耗电量：0.015mA * 24h * 365 ≈ 0.131Ah；
• 全年总耗电约1.78Ah。

如果按38Ah总容量、年耗电1.78Ah来计算，理论寿命超过10年。但这是理想值，实际使用中信号差时通信时间会成倍拉长，低温下电池容量也会打折扣。我在项目里做设计时，按3到5年寿命来评估容量是更稳妥的做法。如果设备设计使用周期超过5年，建议把电池仓做成可更换的结构。

3.2 低功耗设计中的几个实测坑

这几个坑几乎每个项目都会遇到，我踩过之后印象特别深。

第一，传感器不能一直上电。很多人为了省事，让传感器常供电，觉得只有几毫安无所谓。但积少成多，几毫安乘以8760小时一年就是几十安时，电池根本扛不住。正确做法是用一颗MOS管或者模拟开关控制传感器的电源，每次采集前100毫秒才给传感器上电，等读数稳定后再断电。

第二，通信模块不能“裸奔”。NB-IoT模块在接入网络、注册网络时有一个高功耗过程，如果你每次上报都让模块重新搜网、附着，功耗可能翻好几倍。好的做法是让模块上报完成后进入PSM低功耗状态或eDRX扩展不连续接收状态，保持网络注册信息，下次上报时直接唤醒发送，省去搜网和附着的阶段。

第三，信号差的点位功耗会剧增。一个点位的NB-IoT信号在-105dBm以下时，模块会自动提高发射功率，单次上报时间也可能从3秒拉长到5秒甚至更久，功耗跟着增加。所以在设备安装验收环节，必须实测现场信号强度，信号低于-110dBm的点位要重新考虑天线位置或者调整方案。

4. 从设备到平台：数据上报、边缘计算与预警阈值

4.1 数据协议与上报机制：常规周期上报加汛期加密上报

地埋式积水监测站的数据链路并不复杂，设备端采集水位、电压、信号强度等参数，通过NB-IoT网络以MQTT或CoAP协议上报到监测平台。这里的关键不是协议选什么，而是上报节奏怎么控制。

我常用的上报机制是“常规周期+事件加密”的组合。无积水或低水位时，设备每小时上报一次，主要用于设备在线状态监测；水位超过第一级预警阈值后，自动切为每1分钟加密上报；超过第二级阈值后，进一步切为每30秒一次；水位回落且稳定后，再恢复常规周期。这样一来，平台在任何时刻都能拿到足够密度的数据来支撑预警判断，同时也不会白白消耗电池。

下面是我在一套项目中使用的数据报文示例：

{ "devId": "DZ-DM-031", "ts": "2025-07-12T14:32:00Z", "level": 0.23, "battery": 12.6, "rssi": -82, "alarmLevel": 1 }

其中level单位是米，保留两位小数；battery是设备电池电压；rssi是通信信号强度；alarmLevel是设备端判断的报警等级（0无报警，1为关注，2为预警，3为警情）。字段尽量精简，因为NB-IoT虽然按流量计费成本已经很低，但报文字节数越多、空中传输时间越长，对功耗的影响就越明显。

4.2 设备端边缘判断：不能什么事情都扔给平台

有些项目偷懒，设备只做纯采集，所有阈值判断交给平台。这样不是不行，但存在两个短板：一是平台判断依赖完整的数据到达，设备离线时现场就成了盲区；二是平台处理有延迟，部分场景下预警下发到管理人员手机的速度会变慢。

所以地埋式积水监测站最好具备边缘判断能力。我在设备端固件里做了三档判断逻辑：

• 限值报警：水位超过本地设定的第一/第二阈值，立即触发加密上报；
• 变化率报警：水位在短时间内急剧上涨（比如5分钟内上涨超过15cm），即使没有达到绝对阈值，也要上报“快速上涨”状态，用于短临预警；
• 设备自检异常：包括传感器断线、电池欠压、通信连续失败计数，这些状态信息随下次上报一并反馈到平台。

这套边缘逻辑非常管用。有一次城市突降暴雨，某下穿隧道的水位在10分钟内从10cm涨到35cm，变化率报警先于限值报警触发了远程广播提醒，现场车辆及时疏散，没有出现车辆涉水熄火的情况。

4.3 内涝预警阈值怎么定才合理

阈值不是拍脑袋拍出来的。积水的危害程度和水深、水流速度、车辆涉水能力都有关系。我结合工程经验给出一个参考基准：

这里要特别提醒：阈值设定后不是一成不变的。不同点位的道路等级、排水能力、周边汇水面积都不一样，同样的30cm积水在宽阔主干道和窄桥涵下的风险完全不同。设备上线后应该根据至少一个汛期的实际运行数据回看阈值是否合理，再滚动修正。

5. 施工安装与调试：成败在看不见的地面以下

5.1 点位选择与基坑施工的关键要领

地埋式设备的点位选择，表面看是选低洼点，实际上需要多方权衡。我的选址优先级是：下穿隧道最低点、桥涵最低点、地下车库入口坡道、历史易涝路口、排水管网末端溢流点。点位要同时避开雨水口正上方、大树正下方（落叶堵塞风险）、施工频繁路段。

基坑开挖是第一个分水岭。设备外壳要承受车辆反复碾压，基础必须稳固。标准做法是开挖到规定深度后，底部浇筑混凝土垫层，等强度达标后再放入设备外壳，四周用细石混凝土回填密实。如果回填不实，车辆碾过后外壳会发生位移，导致外壳与路面之间出现高差，不仅影响美观，还会产生噪声和安全隐患。

基坑深度还要考虑冻土层。在北方城市，基坑必须深于当地冻土深度，避免冬季冻胀把设备顶起来。南方城市虽然不存在冻土问题，但要考虑地下水位高的区域，设备基坑要做好排水处理，避免基坑长期泡水导致固定结构松动。

5.2 防水、线缆密封与防淤堵的实测教训

地埋式设备的生命线就是防水。设备外壳标称IP68防护等级，但这不等于安装时可以随意接线。外壳上的电缆引入口哪怕有一个密封圈没压紧，地下水和雨水就会慢慢渗进去，初期表现为数据漂移，后期直接腐蚀主板。

我在一个项目中吃过亏：施工人员图省事，把传感器线缆穿过外壳后没有用防水接头，而是直接用普通电工胶带缠了两圈，第一场台风过后三台设备全部数据异常。拆回来一看，线缆内部已经进水，铜芯氧化发黑，传感器输出完全偏掉。后来所有线缆进线口全部换成带锁紧头的格兰头，内部再用双组份环氧胶灌封，没有一台再出过这问题。

防淤堵同样重要。城市道路积水夹杂着泥沙、树叶、烟头，静压式传感器的导压孔如果直接面对水流，很容易被堵住。设备结构上要保证导压孔侧开或者加装挡泥结构，底部留出沉淀空间，让泥沙只淤积在沉沙腔而不直接影响膜片。即便如此，维护周期内也必须安排清理。

5.3 上电调试与验收流程：不要跳过注水试验

设备装好不是通完电就完事了。我要求每个点位必须走完整套调试流程：

1. 设备未封盖前，用水平尺复核外壳顶面与路面齐平；
2. 向井内注水到固定深度（常用20cm），静置5分钟，比对平台显示值与实际水深的误差，要求误差在正负1cm以内；
3. 模拟抬高水位到预警阈值以上，确认设备触发加密上报、平台产生预警事件；
4. 测试本地手抄模式，确认维护人员到现场通过蓝牙或红外读取的数据正常；
5. 检查信号强度，记录上行的rssi值；
6. 盖好外壳，模拟车辆碾压通过，确认无异响、无晃动；
7. 连续观察24小时，确认设备在正常周期内稳定上报数据。

这套流程看着繁琐，但能筛掉90%的后期故障。尤其是注水试验，能直接检验传感器安装深度、导压孔通畅度和零点校准是否正确，千万别省。

6. 运维一年后的故障排查链路：用实际案例拆解

6.1 数据长时间不更新，先从哪个环节查起

设备上线运行一段时间后，最常遇到的就是某个点位数据“卡死”不刷新。很多工程师第一反应是怀疑设备坏了，直接跑现场拆机，其实这样做效率很低。我建议按“平台→网络→设备”的顺序排查：

• 第一步：查看平台上该设备最后一次上报的rssi值。如果rssi突然从-80dBm掉到-115dBm以下，大概率是信号问题，先联系运营商确认基站状态；
• 第二步：核对SIM卡状态。NB-IoT设备长期运行后，SIM卡可能因为资费到期停机，或者被运营商侧做了物联网卡限速、关停。这类问题在平台上往往显示“离线”，但设备本地自检灯是正常的；
• 第三步：用维护终端通过近距离通信读取设备日志，确认设备是否在尝试上报。如果设备侧日志显示网络注册失败，再进一步排查模块和天线；
• 第四步：检查电池电压。如果电池电压掉到保护阈值以下，设备会进入低功耗保护模式，暂停上报，只维持最小系统待机。

我有一次排查到凌晨，最后发现问题出在运营商对某片区域的NB-IoT基站做了升级，设备注册信息被清空，重新附着需要主动重启模块。后来我在设备固件里加了一个“连续多次上报失败自动重启模块”的看门狗逻辑，这个问题就再没出现过。

6.2 传感器数值明显偏高或偏低：漂移和堵塞的分辨方法

传感器读数漂移是压力传感器不可避免的物理特性。设备运行一年后，零点漂移个1到2厘米很常见。但如果出现明显系统性偏差，通常能从数值特征上分辨问题根源：

• 读数整体偏低，且数据曲线比实际降水过程“钝”：多半是导压孔被泥沙部分堵塞，水体压力传递不及时；
• 读数整体偏高，且长期不回落：多半是密封腔进水，产生额外静压，或者大气导气管被堵塞导致内部压力异常；
• 读数跳变剧烈、毫无规律：优先怀疑线缆接头进水、内部连接器氧化造成的接触电阻变化；
• 温漂明显：白天高、夜里低，数值随气温变化，很可能是传感器膜片上有水蒸气凝结。

现场处理时，我一般会带一个透明量杯和标准水尺。先打开外壳，把传感器从井内提出，记录空气中读数（应接近0cm），再放入已知水深的容器中比对。如果空气中读数不为0，说明零点需要校准；如果放入水中读数偏差大，说明传感器本身需要更换。

6.3 电池寿命的远程评估与管理

电池电量不能只看平台上报的电压。锂亚电池有一个特性：空载电压很高，带载时电压会立即跌落。如果只看空载电压，你会发现一个用了三年的电池电压依然在3.6V以上，感觉还能坚持很久，但通信模块一发射就掉到3.0V以下，设备频繁重启。

正确的评估方法是结合两个维度：一是看设备上报的通信信号强度，信号差意味着同等上报次数下电池消耗更快；二是看上报频率统计，如果某个点位频繁触发加密上报，它的电池寿命一定比普通点位短。我会在平台上为每个设备计算一个“等效消耗指数”，综合信号、频次、电压三个参数，当指数接近设定红线时安排更换。

另外提醒一点：更换电池组时，就算旧电池电压还没掉到最低，也建议成组更换。新旧电池混用会造成内部互充电，损耗更大。

7. 几个只有实测后才会告诉你的建议

最后分享几条从我项目经验里总结出来的小建议，不一定写进规范里，但用了都说值。

第一，地埋式设备交付前一定要做满载碾压测试。不要以为外壳上写着承载等级就万事大吉。我参与的项目里，有一款外壳通过了实验室静压测试，但实际装上后，满载渣土车反复碾压导致外壳轻微形变，密封面出现缝隙。后来在验收标准里增加了“满载车辆连续通过20次，检查密封性和数据稳定性”这一项。

第二，设备一定要留本地调试口。不要只依赖无线远程调试。现场信号弱或者平台端暂时失联时，维护人员能用调试口直接读取数据和状态，能省下大量排查时间。

第三，平台端多做“水位变化曲线”展示，比只做当前水位数显要好用得多。一张曲线图能让值班人员一眼看出趋势——是正在快速上涨还是缓慢回落，这比盯着一个跳动的数字更有决策价值。

第四，条件允许时，在隧道和下穿道路的监测点加装声光报警器。地埋式监测站测到了危险水位后，如果能把报警同步推送到现场的LED屏或者声光报警器上，对司机的直接提醒效果远超手机推送。

地埋式积水监测站不是多复杂的设备，但它把传感器、低功耗设计、物联网通信、城市道路工程和排水业务紧密地结合在了一起。每一个环节掉链子，整个系统都会卡壳。把这篇文章里提到的这些细节做扎实了，你的内涝监测设施才真正能在大雨天扛得住，给出让人信得过的数据。