城市井盖这件事听起来不起眼但真出了事往往就是大事。井盖被盗、破损、被雨水顶开轻则影响市政排水重则行人车辆发生事故。我去年全程参与了一套基于NB-IoT的智能井盖安防与在线监测系统从需求梳理、硬件选型、固件开发到云平台接入和现场部署都走了一遍最后整理了一份完整资料。这篇博文就把它拆开讲清楚包括方案选型、功耗计算、协议设计、平台对接还有现场踩过的那些坑。做物联网终端研发、智慧城市方案的工程师以及正在做相关课题的学生朋友可以直接参考这套思路。1. 项目背景与需求拆解1.1 井盖失守的代价一个中等规模城市各类井盖加起来少说几十万口。污水井、雨水井、电力井、通信井权属不同、管理分散但面对的问题是一样的。最常见的是井盖丢失和破损。铸铁井盖有回收价值一直是盗窃重灾区。哪怕现在的复合材质井盖在偏远路段也会被惦记。井盖一旦缺失裸露的井口对行人和车辆都是巨大风险夜间尤其危险。另一个高发场景是城市内涝雨水顶开井盖却无人知晓等发现的时候排水系统已经出了大问题。传统的巡检模式是人工定期巡查效率低、盲区多。一个班组一天跑不了几条街靠肉眼判断井盖状态很多隐患根本发现不了。还有一类需求是污水井、燃气井的井下环境监测井内积水、有害气体积聚这些东西不开盖根本看不到但一旦出了问题就是安全事故。所以市政部门对智能井盖的需求非常明确能远程知道每一口井的井盖是否在位、是否被非法打开、井内是否积水出现异常要第一时间报警。这就是这套系统要解决的核心问题。1.2 为什么偏偏选NB-IoT无线通信方案不少但井盖这个场景很特殊。井盖安装在路面井体在路面以下设备装在井盖背面或者井壁内侧上面是铸铁盖板下面经常还有积水。这就意味着通信链路要穿过一层金属盖板加土层信号衰减远比地面设备严重。同时设备用电池供电不可能频繁换电设计寿命至少两到三年。再加上部署数量大、分布广不可能每个点位拉线供电。把这些约束摆在一起可选的方案就不多了。WiFi和蓝牙首先排除覆盖距离太短没法组网。ZigBee需要自组网络和网关几十万个点位要布多少网关维护成本直接失控。LoRa技术上可行功耗低、穿墙能力不错但需要自己建设网关和网络运维体系整套基础设施投入不小。4G Cat.4甚至Cat.1模块功耗偏高待机电流压不下来电池撑不住两三年的周期。GPRS看着便宜但运营商已经在退网边缘而且覆盖增益比NB-IoT差20dB以上井下信号基本没戏。NB-IoT的优势是综合匹配度最高。它是运营商级网络不需要自建基站和网关开卡即用。覆盖增强技术让信号能穿透井盖和土层实测在井下环境能保持连接。PSM和eDRX两种低功耗模式让设备待机电流降到微安级电池供电两三年没有压力。单小区支持5万个连接大规模部署也不怕网络拥堵。一句话总结选型逻辑在“地下环境、电池供电、海量部署”这三个硬约束下NB-IoT是当下综合成本最低、工程落地最稳的方案。2. 系统架构设计从井盖到手机告警的四层链路2.1 系统整体架构与数据流整套系统分成四层感知层、网络层、平台层、应用层。感知层就是装在井盖上的智能终端核心由主控MCU、NB-IoT通信模组、传感器组和电池组成。传感器负责采集井盖倾角、振动、井内积水等信息MCU做数据判断和协议封装通信模组把数据通过运营商基站送到云端。网络层走的是运营商部署的NB-IoT基站数据经核心网汇聚后进入物联网平台。平台层承担设备接入、数据解析、存储和设备管理的职责通常直接用运营商或云厂商的IoT平台比如华为云IoTDA、中国移动OneNET、电信AEP也可以自己搭一套轻量级物联网服务。应用层是给管理方用的界面和通知渠道包括WEB管理后台、移动端小程序以及短信、语音告警通知。管理人员打开手机就能看到每一口井的状态收到异常告警后安排运维工单。数据流是这样的终端按设定周期上报心跳状态同时支持事件触发即时上报。比如井盖被人掀开传感器检测到倾角变化终端立刻发起上报平台解析数据后判断告警等级推送短信和手机通知给责任人。整个过程从事件发生到告警送达实测在3到5秒内。2.2 功能与技术指标设计功能设计上我按“安防为主、监测为辅”的思路来划分。安防功能包括三项井盖异动报警倾角传感器检测开盖和移位破坏报警检测剧烈振动比如切割、撬动防盗追踪告警后终端持续上报位置或状态直到管理人员到场。在线监测功能主要面向特定场景积水监测在雨水井、污水井装水浸传感器判断井内是否积水漫过阈值气体监测针对燃气井、化工园区井道选装甲烷、硫化氢传感器温湿度监测部分电力井对温湿度有要求可以一并采集。设计技术指标时也要量化。井盖倾角检测精度做到±1度以内报警响应时间3到10秒单次上报数据量控制在100字节以内待机功耗低于10微安整机防护等级IP68工作温度范围-20到70摄氏度。其中报警响应时间的设定值得说一句。如果阈值太低车辆压过井盖的瞬间就会触发误报如果间隔太长井盖被偷走几秒后运输车就走远追踪难度加大。经过现场测试我们最终把报警确认时间设在5秒左右既能滤除大部分瞬态振动又不耽误响应。3. 硬件设计选型与低功耗实现3.1 主控MCU、NB-IoT模组与传感器选型硬件选型是整个项目最花时间的部分每一颗芯片都要从功耗、成本、供货稳定性三个维度权衡。主控MCU我们选了STM32L431。这颗芯片是Cortex-M4内核主频80MHz算力足够跑传感器算法关键是低功耗表现好STOP模式待机电流约0.3微安配合RTC定时唤醒。成本在10元上下市面供货充足资料也很全。如果不介意多花一点学习成本国产的华大半导体HC32L系列也可以做备选低功耗水平接近价格更有竞争力。NB-IoT模组是通信核心。我们评测过移远BC35-G、BC26、中移M5310A等多款模组最后主推移远BC26。它支持OpenCPU方案也就是用模组内置的ARM Cortex-M0核直接跑简单业务逻辑可以省掉外置MCU整机功耗和BOM成本都能再降一截。不过我们项目里因为带了多路传感器和复杂滤波逻辑还是保留了独立MCU把BC26当纯通信模组用通过AT指令交互。BC35-G是老牌经典稳定性没得说但体积稍大、功耗略高适合对成本不敏感、追求成熟方案的项目做备份。传感器部分最有讲究的是倾角检测。最开始想用简单的倾角开关后来发现精度太差车辆压过的震动就会误触发。最终选了三轴加速度计ADXL345通过测量重力在三个轴向的分量换算出倾角静态精度能做到0.5度左右待机电流23微安非常省电。水浸检测用了最实用的电极式方案两根不锈钢探针伸到井底附近有水时电极间电阻急剧下降MCU的ADC采样电压就能判断积水深度。成本几块钱效果非常可靠。气体检测则用半导体式传感器模块化预留接口不用的时候直接不焊把这个功耗大头省掉。3.2 供电方案与续航估算供电方案决定了这套系统能不能跑到第三年这里是整个设计里最容易出问题的地方。我们选了ER34615锂亚硫酸酰氯电池单节容量19000mAh标称电压3.6V。锂亚电池的特点是能量密度高、自放电率低每年1%到2%非常适合长待机场景。但它有一个致命短板不支持大电流脉冲放电瞬间拉不起200mA以上的电流。而NB-IoT模组在发射状态下的峰值电流能到200到250mA直接接电池会压降严重甚至导致模组重启。解决办法是电池并联超级电容。超级电容承担瞬态大电流输出电池负责持续小电流充电。我们用了两个2.7V、10F的超级电容串联容量够模组发射一次所需接线在锂亚电池输出端加一颗二极管防止倒灌。实际测试中模组最大发射时电池端电压波动控制在0.2V以内系统稳定运行。功耗计算是项目方案里必写的内容我按实测数据估算给大家看。待机阶段MCU在STOP模式约0.3微安ADXL345测量模式23微安BC26进入PSM模式待机电流约3微安加上LDO和采样电路的静态电流整机待机约30微安左右。一天待机消耗0.72mAh。每次定时上报的流程是唤醒MCU传感器采集模组初始化注册网络发送数据包等待平台ACK回到PSM。强信号下整个流程4到6秒平均电流约40mA注意不是峰值电流是含底电流的均值一次上报消耗大约0.06到0.08mAh。每天上报一次加上偶发事件报警一天平均按2到3次唤醒计算总消耗约0.2mAh。两项加一起一天约0.9mAh一年约330mAh。锂亚电池还有自放电和低温衰减实际可用容量按60%到70%计算19000mAh折合约12000mAh续航约三年半。这符合市政项目两到三年换一次电池的预期。4. 设备端固件逻辑与云平台接入4.1 设备端固件逻辑与状态机设计固件最大的挑战是用最省的功耗完成最可靠的通信所以状态机设计是核心。设备上电后进入初始化态配置系统时钟、GPIO、ADC和传感器把BC26模组复位读取存储的上次状态参数。然后进入网络注册态模组执行ATCEREG查询注网状态如果失败则延时重试最多尝试3次。注网成功后进入采集态读取各传感器数据执行滤波算法判断当前状态是否正常。随后进入上报态将状态数据封装成协议包通过模组发送到平台等待ACK后清理资源最后进入PSM休眠态。休眠是功耗控制的关键。BC26在PSM模式下会关闭大部分功能只保留RTC唤醒电流能压到3微安以下。我们设置系统每日凌晨3点定时唤醒上报一次这是考虑基站维护窗口和管理人员作息后的折中时间。同时配置RTC和外部中断引脚井盖倾角异常时通过加速度计的中断引脚唤醒MCU实现事件触发即时上报。这里有一个经验值得分享上电后第一次注网最费电。如果设备在信号弱的地方模组会反复搜索网络电流长时间维持在200mA以上对电池负担很大。所以固件里要加超时保护如果30秒内无法注网成功则直接进入PSM等下一个周期再试不要死磕。关键逻辑用伪代码描述大概是这样系统状态_STARTUP: init_mcu(); init_sensor(); at_ready(BC26); goto NETWORK_JOIN; 系统状态_NETWORK_JOIN: ret at_check_signal(); if (ret FAILED retry_count 3) { retry_count; delay(10s); goto NETWORK_JOIN; } else if (ret FAILED) { enter_psm(); goto SLEEP; } goto SENSOR_READ; 系统状态_SENSOR_READ: 读取角度传感器 读取水浸ADC值 读取电池电压 判断是否异常 goto REPORT; 系统状态_REPORT: 封装上报数据 at_send(); 等待ACK if (ACK_OK) goto SLEEP; else goto REPORT_RETRY; 系统状态_SLEEP: 进入PSM GPIO中断唤醒或RTC定时唤醒 唤醒后重新进入SENSOR_READ状态机并不复杂但每一处延时和重试逻辑都要考虑功耗成本这是嵌入式物联网开发和普通嵌入式开发的本质区别。4.2 数据上报格式与平台接入协议数据上报格式我们用了二进制这是很多人会忽略的细节。NB-IoT虽然带宽不小但每字节都意味着模组更长的发射时间。JSON虽然直观但一个包含20个字段的JSON报文动辄几百字节相比之下二进制报文固定长度只有32字节发射时间缩短一半以上。报文格式设计成这样帧头2字节0xAA 0x55设备IMEI后8位电池电压2字节井盖倾角值2字节水浸状态1字节气体浓度2字节状态字段1字节时间戳4字节保留字段和CRC校验占剩余空间。平台通过解析模组IMEI识别设备数据字段直接按固定偏移量解析效率很高。平台接入我们选了华为云IoTDA原因下面细说。设备端用LwM2M协议接入这是OMA组织的标准物联网管理协议基于CoAP传输专门为低功耗、低带宽设备设计也是NB-IoT模组默认支持的上层协议。模组内部集成了LwM2M协议栈我们只需要通过AT命令配置服务器地址和端口然后直接发送CoAP数据即可不需要在MCU里再跑一套协议。不过这里有个取舍问题。LwM2M的生态和华为云、移动OneNET、电信AEP完全对接开箱即用但报文格式固定灵活性差。如果项目后续要对接自定义后端改用MQTT over CoAP或者直接UDP透传会更方便。我们当时考虑到市政项目大概率要统一设备管理和固件升级选择了标准LwM2M链路后续扩展OTA升级功能也顺手。设备接入平台前要做这么几件事在IoTDA创建产品定义物模型就是数据字段的语义然后把设备的IMEI批量导入再配置数据解析规则。物模型设计是平台接入最核心的环节你可以把井盖设备理解成一个“物体”它的属性包括电量、倾角、积水状态平台通过物模型就知道怎么解析上报的数据。4.3 告警策略与防误报设计告警策略设计得好不好直接决定了这套系统在运维那边是帮手还是天天骚扰人的麻烦精。最初版本的逻辑很简单倾角超过30度就报警。上线第一天后台告警短信像洪水一样涌进来全是车辆碾压、施工震动造成的误报。后来我们加了多重确认机制才解决。第一层是持续确认。倾角超过阈值必须持续5秒以上才触发报警这5秒过滤掉车辆瞬间压过井盖的短暂震动。第二层是二次采样。报警触发后终端强制采集三次数据三次结果都异常才上报事件。第三层是阈值动态化。正常井盖被人为打开倾角通常超过45度而车辆压过导致的微小弹跳一般在10度以内很少超过15度。所以正常工况阈值设在15度告警阈值设在30度两档之间是可疑区只记录不上报。防误报还有一个容易被忽略的小点新安装的井盖安装人员操作时会触发振动和倾角异常。我们做了一个“安装静默模式”设备部署后48小时内只记录不上报给调试阶段留出缓冲期。这个功能让上线首周的历史告警噪音几乎降为零。水浸告警也做了延后处理。电极碰到几毫米的浅水就触发的话雨天会把运维人员烦死。我们设成井内水位持续超过阈值10分钟后才上报表示井内已经形成实质性积水具备排涝参考价值。电池低电压告警则做了迟滞处理只有电压连续三天低于3.3V才提醒避免因为瞬态负载波动反复告警。协议里告警等级做了细分一级告警是非法开盖需要立即处理短信加电话通知二级告警是井盖移位或破损短信通知三级告警是积水或气体异常平台记录并生成工单不强制立即推送。分级设计让运维资源的投入产出比更高。5. 现场实施与实际运行效果5.1 部署流程与现场注意事项设备和平台都调试通过后真正的考验才刚开始现场部署。部署流程分六步点位勘测、设备配置、现场安装、平台绑定、功能验证、交接培训。点位勘测先于一切。勘测时要用标配的NB信号测试设备在每个拟安装井盖旁实测信号强度用ATCSQ命令查看信号值低于12的地方基本不适合安装需要换点位或规划信号增强方案。有些老城区管网密集、井盖在背阴处信号衰减特别严重勘测阶段筛掉一多半点位是常事。没有这一步装上去就是一堆永久离线设备。安装环节同样有细节。设备紧贴井盖背面安装用工业级双面胶加不锈钢扎带固定避开井盖开启时的活动铰链位置。传感器安装面必须平整安装后用手机水平仪校验零位。水浸探针沿井壁向下延伸固定在低于正常水位线20厘米的位置。井盖合上后实测一次上报确认倾斜角读数归零再在平台绑定设备。平台绑定用IoTDA的设备批量导入功能把设备IMEI和位置信息做成Excel表格一次性导入。这里有个教训IMEI一定不要手输手机拍照扫描或者用扫码枪手输极易错一位后面排查起来非常痛苦。功能验证必须实际触发一次报警。把井盖打开到报警角度确认平台收到告警、手机收到通知然后盖回去再确认设备恢复在线并上报正常状态。这一步不能省我见过太多设备部署完没验证后期告警链路不通才发现问题。5.2 运行数据与实际效果系统上线后我们持续统计了三个月的运行数据。设备在线率稳定在98%以上这和信号勘测做得到位有直接关系。每天定时上报成功率接近100%偶发一次失败会在下一周期自动补报。整个三个月里系统共触发68次倾角告警经人工核实62次是车辆事故或施工碰撞造成的井盖移位6次是真实的小偷尝试开盖。其中5次在警方到场前设备就已发出告警并持续上报位置最终成功阻止了盗窃。剩下一次发生在凌晨三点的偏远路段可能因为响应太慢设备仍被撬走但好在持续上报让警方在四个小时后找到了被丢弃的井盖和作案工具。水浸报警在雨季表现尤为突出。一次强降雨中平台在两小时内陆续上报了12个积水点水位超限市政排水部门根据这些实时数据调度抽水车比往年靠人工巡查反馈缩短了一半以上的响应时间。这是整个项目最让我有成就感的部分物联网设备的价值不是单纯替代人工而是把过去根本不可能感知到的信息流变成实时的数据流。5.3 常见问题与排查实录整理几个现场高频问题都是实际踩过的坑。第一个是设备频繁离线。排查流程是先看平台是否显示设备最后通信时间然后用ATCEREG?查询注册状态如果返回3表示拒绝注册那基本是物联网卡问题查一下流量是否用尽、APN是否配置正确如果返回0或2表示在搜索网络那就是信号问题用ATCSQ看信号值信号值连续低于10果断换点位或者加装外置高增益天线。还有一种隐蔽情况是运营商侧设置了PSM定时器过期时间设备进入PSM后超过有效期没有周期性上报平台把设备标记为离线。这需要对运营商侧的TAU周期参数做配置让设备保持长周期在线状态。第二个是误报警。前面讲的防误报机制上线后误报率降了90%以上但仍有零星情况。排查后发现多发生在大型载重车频繁通过的工业园区路段车辆连续碾压造成井盖持续性小角度位移累积值超过阈值。针对这种情况我们在固件里加了“疲劳计数”逻辑同一位移状态需要在12小时内出现3次以上才触发告警才算真的异常。第三个是电池低电量告警过早出现。有几台设备安装后半年就报了低电量排查发现是超级电容失效模组发射时电池电压被拉低单片机误判为电量不足。更换同批次另一类型号的超级电容后问题消失。这里要特别提醒超级电容选型时注意漏电流参数漏电流过大的型号会持续消耗电池能量在长待机场景里非常致命。第四个是井盖复位后设备不回状态。井盖盖上后倾角恢复为0但设备在PSM模式下要等下一个唤醒周期才会重新上报正常状态中间这十几个小时如果管理人员只看平台会一直以为井盖还是打开状态。后来我们设置了本地传感器中断唤醒逻辑倾角恢复零位超过10秒就唤醒设备上报一次把状态同步时间缩短到秒级。6. 投入产出分析与适用范围6.1 成本构成与效益分析不少朋友问这套系统到底值不值得做我从成本账算给你看。单套设备硬件成本大概是MCU加传感器加通信模组加电源和结构件批量采购下不到150元。电池按三年寿命采购分摊到每年约40元。物联网卡按NB最低套餐计每年20到30元。平台接入按连接数计费每月一元出头每年15到20元。综合下来单点位的年运营成本在70到90元区间。这个价格在城市基础设施管理预算里非常有竞争力。与之对比传统人工巡检单车位成本很高按巡检频次、人力成本和交通成本折算一个工人一天最多巡检100口井和系统全天候无死角监测完全不是一个量级。真正的回报不止是省钱而是把“井盖丢失后找到”变成“井盖被盗前报警”把“雨后人工排查积水”变成“实时水位地图调度排涝”这些都是无法用简单数字去衡量的管理价值提升。6.2 这套方案的适用范围与拓展空间做项目过程中我越来越确定这套方案的通用性远远超出井盖本身。同样在市政领域消防栓被撞倒、电线杆倾斜、路灯杆倾倒、绿化带灌溉管道泄漏本质上都是“室外固定资产状态监测”问题传感器加NB-IoT加平台的三件套完全通用。我给朋友改造过一个消防栓监测原型只换了传感器固件和平台逻辑几乎原封不动两周就完成了验证。在工业领域管道阀门开度监测、储罐液位报警、泵站漏水检测核心逻辑也一样。在农业领域田间水位、土壤湿度、设备防盗监测同样可以用这套架构。NB-IoT的低功耗长待机特性决定了它天然适合那些“位置分散、无市电、不需要实时大流量”的场景。如果后续要拓展更多传感器这边的建议是先确认平台物模型扩展能力。IoTDA支持物模型灵活扩展新增一个传感器字段只需要开发端加两个字节的数据上报再把物模型字段加上去即可。硬件端预留传感器接口固件支持配置多路ADC输入后续扩展成本会非常低。项目做完沉淀下来的最大体会是物联网项目真正难的从来不是单一技术点而是如何把低功耗硬件、可靠通信、平台解析、业务系统这些环节串成一条稳定的闭环。这套系统的完整资料从原理图、PCB、固件源码到平台配置文档都有我会在后续文章里陆续拆解。先消化这篇整体框架有任何细节问题欢迎在评论里交流。最后分享一个做项目的方法。第一次做这类系统时最好先在一个条件完美的院子或者阳台上做桌面联调确保固件、平台、告警链路都通再跑现场实测。千万不要一上来就装到真实井盖下信号差、环境恶劣、排查全靠蹲在路边开井盖调试效率会低到你怀疑人生。先在干净环境把问题隔离掉才是最快的落地路径。