2025年我在恒星物联主要做的事情就是围着“城市生命线”转地下管网的压力传感器、燃气井里的可燃气体探测器、桥梁上的位移监测节点、智慧城市运营中心里的那块大屏。年终写下这篇回顾既是替团队做个交代也是给还在物联网和智慧城市这条赛道里摸爬滚打的同行留点可参考的东西。文章不打算写得太“新闻通稿”毕竟技术上的甜头和槽点只有干过的人才知道。1. 城市生命线为什么2025年成了转折点1.1 城市生命线项目到底是什么城市生命线这个提法早几年在行业里更多是规划文件里的概念但从2024年下半年到2025年它已经变成了实打实的工地围挡、现场勘查和上墙的管线图。所谓“生命线”指的就是城市的供水、排水、燃气、供热、电力、通信、桥梁、地下管廊这些基础设施。它们平时不起眼但任何一条出了问题轻则小区停水停气重则路面塌陷、燃气爆炸。靠人工巡检根本盯不住地下几万公里的管网这时候物联网的价值就出来了——在关键节点装上感知设备把压力、流量、气体浓度、位移、液位等参数实时传到后台再由智慧城市系统统一调度。2025年之所以成为转折点我总结下来有三个直接原因。一是设备成本降下来了。NB-IoT模组和4G工业模组的价格比三年前低了差不多一半让“每公里管网都有监测点”这件事从预算上变得可行。二是政策端的底线要求更明确各地对燃气、排水、桥梁的安全监测覆盖率有硬性指标。三是平台侧的工具链成熟了开源物联网平台、时序数据库、可视化大屏这些组件都能直接拿过来改不再需要从零造轮子。恒星物联这一年能同时推进多个城市的项目本质上就是吃到了这三个红利。1.2 恒星物联的年度定位从卖设备到交付系统早几年我们公司的业务模式很简单卖传感器、卖网关交付完硬件就结束。到了2025年这个模式彻底跑不通了。甲方要的不是“你有一批设备”而是“你能证明管线状态可感知、风险可预警、事件可追溯”。所以恒星物联这一年最大的变化是从设备供应商转成了解决方案服务商。交付内容变成了一整套东西感知层设备、边缘网关、通信链路、数据平台、告警规则、移动端工单、值班大屏以及最重要的——持续运维。这个转型带来的技术压力是实打实的。原来硬件交付完坏了自己返修就行现在系统上线后数据质量、告警准确率、平台稳定性全都要兜底。2025年我们最忙的不是新项目开工而是老项目的运维和迭代。这也逼着我们把网关和平台做成了相对标准化的产品而不是每个项目单独定制。标准化之后多项目复用成本明显下降现场实施周期从原来的两三个月压缩到一个月以内。这个教训值一年工资做物联网项目千万别每个客户都重新发明一次轮子否则交付团队累死公司利润也薄得可怜。2. 硬件端的核心拆解从感知节点到边缘网关2.1 传感器选型与部署从电池供电到无源物联网的尝试硬件选型是所有城市生命线项目的第一步也是后面所有麻烦的源头。传感器选型我给自己定过三条铁律量程余量不低于实际工况的1.5倍防护等级至少IP65涉水管道井里甚至是IP68单次采样功耗控制在毫安级以下通信功耗按“半天一次”的节奏来设计。拿燃气井里的可燃气体探测器来说2025年主流方案还是催化燃烧式传感器虽然它有零点漂移的问题胜在成熟、便宜、对甲烷敏感。真正头疼的是它的工作电流动辄几十毫安如果用电池供电一个18650电芯也就撑两三个月。所以这类节点普遍采用“电池微功耗管理模式”平时传感器和通信模块全部休眠每天定时唤醒上报一次遇警立即上报。但2025年有个新东西开始从实验室往工程现场走就是无源物联网。我们在一批雨水篦子和井盖上试了射频无源方案——设备本身不带电池靠专门的读写器发射射频能量给节点供电节点再通过反向散射把数据传回来。这套方案的好处很直接不用换电池、没有电池低温失效问题、防盗反而更好做。缺点是通信距离短读写器与节点之间几十米就是极限而且容易被遮挡。用了一轮下来的感受是它暂时替代不了电池方案但在“井盖状态”“低洼积水深度”这类低频、近距离、低数据量的场景里确实能省掉一大笔电池维护成本。2026年如果读写器的成本再降一截这个方向会明显放量。2.2 STM32FreeRTOS物联网网关为什么没上Linux网关是整个项目里我最想聊的部分。城市生命线项目的现场环境很恶劣地下井里高温高湿、桥梁上温差大、路边机箱可能被恶意断电。网关要承担的任务是汇集下面挂载的传感器数据做初步的滤波和告警判断然后通过4G或有线网络把数据传到平台。2025年我们主力网关用的是STM32MP系列或者更高端的STM32H7配合FreeRTOS跑多任务。很多人问我为什么不用树莓派或者工业Linux盒子答案是功耗和可靠性。Linux方案的CPU动不动几十毫安到上百毫安散热量也大在密封的防水机箱里很容易过热死机。STM32FreeRTOS整机平均功耗可以压到几毫安而且没有操作系统那套驱动兼容性问题极端情况下硬复位也更可靠。FreeRTOS在这个项目里的任务划分其实非常有讲究。我用的是经典的四任务模型采集任务负责从I2C、SPI或RS485总线上轮询挂载传感器、协议转换任务把串口协议或者Modbus报文转成设备影子模型、网络管理任务维护MQTT连接、心跳保活、断线重连、OTA升级任务通过HTTP或者MQTT差分升级固件。四个任务之间用队列传递数据缓存区用环形缓冲区管理。任务优先级的经验是采集任务优先级最高因为它吃实时性网络任务优先级次要但要防止阻塞采集。踩过最痛的一个坑是MQTT阻塞式发布导致采集任务饿死后面改成了“采集任务只管放队列网络任务只管消费队列”问题就消失了。2.3 4G物联网模块可靠性才是最大的隐形成本搜一下“4g物联网模块容易坏吗”你会发现这是很多做物联网的人都被困扰过的问题。我的回答是模块本身极少无缘无故坏坏的基本都是外围设计。2025年我们遇到最多的三类故障第一是电源瞬态击穿第二是雷击和地电位反击第三是天线失配导致信号反复重连。前两类往深里说都是电源和防护设计不到位。很多开发板级的应用直接给模块供3.8V电压纹波一大会导致模块随机重启城市户外现场的线缆长感应雷很容易顺着供电线进来打坏主控。第三类则是天线馈线被老鼠咬断、或者安装工人把天线和电源线绑在一起信号被严重干扰。解决这些问题的做法2025年已经变成我们内部的标准设计规范。电源端必须做“防反接TVS管共模电感DC-DC隔离”模块用独立的LDO供电输入电压范围放宽到9V到36V兼容工业现场常见的24V。雷击防护要在机箱入口做气体放电管和压敏电阻配合的二级防雷接地电阻实测不小于4欧姆。天线必须用外置吸盘天线尽量远离金属机箱底部馈线走向与电源线垂直避免平行捆扎超过20厘米。另外建议在固件里把“信号强度、驻波比、重连次数”作为诊断指标周期上报这样才能在设备还没彻底离线之前就发现链路质量恶化。这些细节看着琐碎但城市生命线项目一旦设备大面积离线运维压力指数级上升甲方在月度例会上能把人盯到发慌。3. 平台侧与交付把数据变成“城市体检报告”3.1 物联网平台选型基于开源ThingLinks二次开发的取舍硬件只是骨骼平台才是神经系统。平台选型在2025年摆在我们面前的选择无非三条用云厂商的物联网套件、买商业IoT平台、基于开源平台二次开发。恒星物联最终选择的是基于开源物联网平台ThingLinks做二次开发原因很朴素城市生命线项目的部署环境太多样了有的客户要求数据必须本地化部署不允许上公有云有的客户自己有政务云要求我们提供安装包还有些项目规模小预算有限商业平台的license费用占掉一大块。ThingLinks解决了我们最痛的那部分——设备接入层的协议适配、设备管理、规则引擎、告警中心这些都是现成的不用从零写。代价是它默认的界面比较朴素物模型的表达能力和我们需要的管网专业模型有差距这两块我们前后投入了两个开发月去做定制。选型过程中我们做过一个技术对比表核心维度是五栏设备接入协议灵活度、离线数据缓冲能力、多租户能力、二次开发门槛、部署方式。云厂商的套件在设备接入和运维监控上很强但私有化部署授权费贵商业平台功能全但自定义数据模型时黑盒太多ThingLinks在二次开发上最开放部署也最灵活缺点是社区版的功能边界需要仔细测试一些涉及高并发路由的底层代码要自己改。如果让我给后来者一个建议团队里只要有两个人能读得懂Java代码且项目有强私有化诉求选ThingLinks这条路是稳的如果团队全是前端或者嵌入式工程师那还是踏踏实实付费买商业平台省下的研发时间远大于license成本。3.2 数据流转链路从设备上报到告警闭环平台定下来之后最重要的事情就是把数据流转链路想透。城市生命线项目的典型数据链路是现场传感器→串口或RS485总线→边缘网关→4G/NB-IoT网络→物联网平台设备接入层→消息队列→规则引擎→告警服务→业务工单系统→大屏和移动端。这条链路里最容易出问题的环节不是大家以为的硬件而是设备与平台之间的数据“语义”对齐。我们跟甲方开了无数次物模型评审会反复确认“压力值是什么单位”“液位正常范围是多少”“什么情况下算三级告警”。如果前期物模型定得稀烂后面所有告警阈值、大屏图表全要返工。数据链路设计上有几个工程化心得值得展开。通信协议全部统一走MQTT over TLSQoS级别用1QoS 0对城市生命线这种场景太不可靠QoS 2对网关内存开销太大现场大量低性能设备扛不住。MQTT的Topic结构按“项目编码/设备类型/设备编号/属性”四级组织payload格式先用标准JSON但把上报数据和设备元数据分开避免每包数据都带冗余字段。为了应对信号盲区网关本地开了环形数据库缓存断网时数据先存本地网络恢复后按时间戳补齐上报平台侧用“时间戳设备ID”做去重。时序数据入库用的TDengine压缩率和查询速度都比MySQL裸存要好一个量级一个月的数据量在几十亿条的情况下聚合查询还能秒回。3.3 告警规则与闭环处置智慧城市不只是“响警报”平台如果只做到“收到数据、显示曲线”那还是半个摆设。2025年我们花了大半精力做告警的“闭环”。城市生命线的告警逻辑跟普通物联网告警不一样它讲究的是“防误报、防漏报、快速定位、协同处置”。我们用规则引擎配置了多条件组合告警比如某段供水管网的压力异常并不是压力一超限就立刻告警而是结合“离线持续时长、压力变化速率、当日时段”综合判断。夜间用水低峰时压力短时升高很可能是泵站调度的正常操作但如果在用水高峰出现压力骤降那大概率是爆管必须第一时间推送。告警推送之后的一整套处置流程也做进了系统平台生成告警工单→按区域和值班表派发到对应班组→处置人员在移动端接单填报现场排查结果→处置完成后平台归档并自动生成月度风险分析报告。这个闭环的价值在于它把一次偶然的设备告警沉淀成了城市风险数据库。到年底我们复盘时发现某个城区的燃气浓度告警虽然大多数是误报但集中在某几个井盖背后是地下沼气积聚的规律性风险。这种洞察靠人脑统计不出来必须靠智慧城市系统把数据攒到一定量级之后才能浮现。4. 一年踩过的坑维护、排查与避坑实录4.1 雷雨季的“集体离站”事件接地问题排查全过程2025年夏天是让我们印象最深的一个季节。雷雨来了三天某项目现场连续有几十个4G网关掉线平台上的设备在线率从98%直接掉到70%。仪表盘上看全是“离线”一开始怀疑是运营商基站故障让甲方打了运营商客服基站侧说一切正常。后来又怀疑是网关固件崩溃结果邮件确认后发现各个设备掉线前都有几天的“信号强度逐渐变差”的记录我立刻意识到这波不是软件问题是硬件被渐进损伤。带着排查仪到现场后我先测了网关外壳对地的交流电压毫无悬念地高达十几伏说明机箱接地不良。再拆开网关检查电源板发现DC-DC模块输入端有一个电容已经鼓包TVS管也烧黑了。这三个现象串起来就清楚了雷击时感应出的瞬态高压没地方泄放顺着电源线和机箱缝隙侵入主板把防护器件逐个打穿设备在雷击后并非立刻死机而是电源纹波越来越大扛了几天才彻底“断气”。解决方案分两步走短期把现场所有网关的接地线重新打桩确保接地电阻达标长期改了网关的电源入口设计把压敏电阻的标称电压调高并增加了一级气体放电管。经历过这一轮之后“雷雨季提前一周做接地巡检”写进了我们公司的运维SOP。4.2 电池供电节点的寿命账怎么算才能不翻车城市生命线里很大一部分节点没法拉市电比如井盖下的液位传感器、桥梁伸缩缝里的位移计。电池供电是必然选择但电池寿命怎么算2025年我们被现实教育了好几轮。最开始我们按厂家手册给的理论值报的电池寿命是三年结果现场不到一年就有节点电量报警。原因不难猜理论值按常温、低频采样、完全理想射频链路算现实中井盖下的温度夏天能到50℃以上电池自放电率翻倍通信模块发射时的瞬间电流高达2A如果电源走线太长压降太大还会导致模块反复重启额外消耗电量。后面我总结出一套务实估算公式平均工作电流约等于单次采集功耗×日采集次数 单次通信功耗×日通信次数÷ 86400秒再加上传感器休眠电流和DC-DC静态损耗最后再乘上1.3的工程冗余系数。拿一个每天采集4次、通信4次的井盖液位节点来算如果单次通信需要120mA持续2秒那一块12Ah的电池按90%放电深度来算理论上能用2年出头实际的1.3倍冗余后就只有1年半左右。所以我们2025年下半年的新项目里果断把这类节点的上报频率从每天4次降到了每天2次并把非告警状态下的通信压缩成“只上报心跳和变化阈值”电池寿命预期直接拉回到2年半。教训很朴素电池寿命账宁可算保守一点不然项目交付后的两三年你会一直被换电池的需求淹没。4.3 现场施工导致的“软故障”设备没坏但数据乱跳很多物联网项目出现怪问题不是设备坏了而是安装施工不规范。2025年有一笔投诉很典型某桥墩上的倾角计数据每隔几分钟就跳变一次最大偏差甚至达到0.5度看起来就像桥梁要倒。当时甲方非常紧张我们连夜上线了原始数据日志排查发现跳变具有明显的周期性每隔约7分钟出现一次。后来现场拍照确认是施工方把倾角计的供电线缆和旁边一个变频水泵的电缆布在了同一根线槽里。变频器启动时在供电线路上产生了强烈的电磁干扰传感器的模拟前端被干扰后读数直接跑飞。解决过程分了两层。硬件层面给传感器供电加装了EMI滤波器并把全部模拟量采集改成差分输入同时把采样时序做了校准避开变频器的开关噪声窗口。施工层面强制要求规范传感器线缆必须与动力线分开穿管间距不小于30厘米现场如果交叉必须走90度垂直交叉并用金属屏蔽管过渡。这套规范后来直接变成了我们给所有分包商的进场技术交底内容。我后来偶尔看到有人说“为什么我买的传感器精度这么差”其实很多时候精度指标本身没问题是现场的电磁环境和施工工艺把性能拖垮了。设备精度是基础工程安装的规范性才是下限。4.4 平台侧的物模型变更之痛版本管理不能偷懒城市生命线项目里设备类型杂、品牌多物模型的变更几乎无法避免。最痛的一次变更发生在10月份某品牌更新了燃气探测器的固件把原先上报的“浓度百分比LEL”直接改成了“无量纲的浓度值”同时新增了一个报警状态位。如果没有预判平台上所有历史告警阈值规则全部失效之前攒了半年的数据对比直接断裂。这件事给我们上的课就是物模型必须纳入版本管理。现在我们定的规矩是三条第一所有物模型修改必须走评审流程不允许开发人员直接在代码里改字段第二平台侧增加“设备影子数据格式转换层”同一型号设备的不同固件版本对应的上报格式在平台侧做兼容转换而不是逼迫现场设备一次性全部升级第三每次物模型变更都要写清影响范围包括历史数据的处理方式。做完这三件事之后我们再遇到厂商突然改协议的坑系统侧的适配成本从原来的几周降到了几天。物模型表面上是个技术概念本质上是项目的“业务契约”。契约不稳定上层所有应用都跟着飘。5. 对2026年的几个判断和个人体会站在2025年年底回望我对2026年的城市生命线趋势有三个明确判断。一是无源物联网的试点范围会显著扩大尤其是在井盖状态、消防通道占压这类低功耗低频次场景它会从“实验性”项目变成“常态化”采购项。二是边缘网关里的AI能力会开始实用化比如在网关侧直接做燃气管网泄漏的声纹识别前置判断让数据在产生地就被消化掉而不是全往平台端倒。三是平台侧的标准化程度会进一步提高物模型和接口规范会向行业标准看齐那种一家一个私有协议的时代会慢慢过去。最后说点个人的体会。2025年给我最大的感受是智慧城市和物联网这两个词已经过了讲故事的阶段大家比的都是谁的系统更稳、告警更准、响应更快。很多看上去“高大上”的需求落到现场就是一根线怎么走、一个地桩怎么打、一块电池怎么省。这一年我经常跟团队讲宁可项目工期慢一周也要把现场的安装规范做扎实宁可设备成本高一点也要选成熟稳定而不是参数好看的方案。城市生命线项目没有“重来一次”的机会因为它守护的是千万人的日常。做这一行靠的就是把每一个细节抠到极致。2026年继续走。