摘要：当下工业设备运维越来越依赖远程监控，很多团队搭出来的设备远程状态监控查看平台要么华而不实，要么频繁翻车，真正能用能解决问题的没几个。本文结合我近五年做过的十多个工业现场项目，聊聊实际落地中藏在说明书背后的设计细节，以及踩过的真坑。
核心需求拆解：别上来就堆硬件
很多刚接这类项目的工程师，拿到需求第一反应就是选最贵的网关、买最大的云服务器带宽，恨不得把所有参数都一秒一次往平台传。
去年我给珠三角一家水泥厂做回转窑远程监控项目，甲方一开始拍板：所有数据都要高频采集，一个点都不能落。我拉着运维主任蹲现场看了三天，最后把采集频率分成了三级：主轴振动、窑头温度这一类核心故障参数，1秒采一次传一次；托轮轴承温度、润滑油压这类重要参数，10秒一次；油位、环境温湿度这类非关键参数，30分钟一次就够。
省了多少成本？算下来带宽和存储成本直接砍到原来的八分之一。甲方老板笑到不行，说原来还准备每年掏十几万带宽费，现在一万多就搞定。
说实话，大部分中小工厂真不需要全量全频采集。你得先搞清楚，平台给谁用？要解决什么问题？如果只是给老板看一下设备开停状态，那NB-IoT模块就够，几百块就能搞定一台。如果要做预测性维护，那边缘侧就得提前做FFT振动分析预处理，只传特征值，不然原始振动数据一天就能把带宽占满。
我见过最离谱的项目，平台做了十多套统计图表，3D模型也做的很漂亮，现场运维要找最关键的轴承温度，得点四下菜单。最后上线不到一个月，运维干脆不用了，还是每天跑现场抄表。钱花了，事没成，怪谁？
边缘与平台的选型权衡：适合的才不翻车
网关选型这块，我必须吐槽。很多团队为了压成本，选那种几十块一块的消费级物联网模块。工业现场什么环境？大功率变频器旁边，电磁干扰能把信号吃的干干净净。
前年帮一个客户排查故障，平台隔三差五丢数据，有时候半天都刷不出来。我们从平台查到云服务商，从云服务商查到现场网关，折腾了半个月，最后发现模块的电源抗干扰不满足GB/T 17626-2018 工业电磁兼容等级3要求，变频器一启动，模块直接死机重启。你说闹心不闹心？
后来换了工业级网关，每台贵了三百多，从此再也没出过丢数问题。省了多少次排查故障的人工？这点钱真的不能省。
平台端选公有云还是本地部署？给个现成的判断标准：100台设备以内，单台日均数据量小于100MB，不涉及核心涉密数据，直接选公有云SaaS，按年付费，一年几千块，比你自己买服务器搭环境省太多。如果是军工、汽车核心制程的设备，必须本地部署，还要过等保2.0三级，这点没得商量。
数据存储这块，很多人踩坑。别用普通关系型数据库存时序状态数据！我之前不信邪，试过用MySQL存100万条温度时序数据，查一个月的趋势图，耗时17秒，换了TDengine之后，不到80毫秒出结果。差距就是这么大。现在我做项目，时序数据必须用专用时序库，没得选。
藏在细节里的坑：都是拿钱砸出来的教训
第一个坑，时间不同步。很多人做完平台，出了故障调数据，发现A传感器的时间比B传感器快了三分钟，根本对不上故障发生的时序。按规范要求，所有边缘节点必须支持NTP网络校时，每天至少自动校时一次，时间误差控制在100毫秒以内，符合GB/T 50770-2013的要求，这点一定要写进验收标准。
第二个坑，报警误报炸锅。很多项目就是简单设个固定阈值，比如轴承温度超过70度报警，夏天现场环境温度比冬天高十度，本来正常运行温度就是65度，稍微一加载就超过70，一天报几十次误警。到最后真报警了，运维都麻木了，直接忽略，出了事故谁担责？现在我做项目，必须做自适应动态阈值，基于近七天同一时间段的历史数据上浮15%到20%设报警，误报率直接降了80%都不止。
第三个坑，不做断网缓存。现场哪里能保证网络永远稳定？有时候园区运维割接，断网三四个小时很正常。要是网关不做本地缓存，断网期间的数据全没了，平台上就是一块空白，真出了设备故障要查记录，你拿什么给甲方交代？要求网关至少留8G本地存储，能缓存至少7天的全量数据，网络恢复之后自动续传，这个功能看着不起眼，关键时刻能救整个项目。
还有UI的坑。别给我搞什么花里胡哨的交互，现场运维大部分人不会玩复杂的系统，你把核心参数直接放在设备列表页，点一下设备就能看到所有历史趋势，一键导出报表，这就够了。我上次做项目，拉着运维班长改了三版UI，才改成他顺手的样子，真的，别自己拍脑袋想当然。
做这个平台，本质就是帮现场运维省脚力，帮老板提前发现故障，别搞一堆没用的花活。把核心需求摸透，该省的地方省，该花钱的地方别抠，把每个细节做扎实，做出来的平台才有人用。
