当前国内工程机械、汽车制造、风电等领域的智能化改造，大多从云端数据采集分析起步，走着走着就发现，带宽成本蹭蹭涨，响应延迟卡脖子，断网就趴窝更是常态。边缘端本地数据计算就是解决这些问题的落地方案，结合近五年做工业智能化项目的实际经验，聊透机械场景下做边缘计算的选型、避坑要点，都是拿钱砸出来的经验。
为什么机械装备现在必须啃边缘端本地计算这块硬骨头
去年给国内某主机厂做车身点焊在线检测项目，踩过一个大坑。一开始甲方要降本，选了纯云端方案，把焊枪的力传感器、超声传感器数据全传到云平台做开裂识别。
一开始试生产没问题，量产后，车间里同时开12台焊机器人，一秒钟产生快2M的传感数据，车间5G信号一挤，延迟直接冲到半秒，偶尔还断网十分钟。有次夜班断网，数据没传上去，漏检了三个不合格的点焊车身，差点流进总装线，差点赔几十万。
后来改成边缘端本地数据计算，所有识别逻辑直接在设备自带的控制器上跑，不合格件出结果只需要80ms，不用传原始数据，只需要把每天的不合格结果汇总传到云端，一个月流量才几百M。成本降了，可靠性还上来了。
不止汽车焊装，风电的变桨故障预警、盾构机的刀盘磨损预测、港口起重机的钢丝绳检测，所有需要毫秒级响应、不能断网趴窝、还要降带宽成本的场景，边缘端本地计算都是刚需。云端用来做大数据汇总、模型迭代就行，实时计算，真的放本地靠谱。
机械场景下边缘端本地计算的选型权衡
很多年轻工程师一提到边缘计算，张嘴就要英伟达Jetson Xavier，觉得算力越高越好。说实话，机械场景大部分应用根本用不到那么高的算力，选贵了不仅浪费钱，还会踩散热的坑。
前年做港口钢丝绳磨损检测项目，整个算法就是轻量化YOLOv5n加传统形态学分割，总共推理不到1G FLOPS，我们最后选了一百多块的ESP32-S3带AI加速核，跑下来推理延迟只有30ms，还支持宽温-40℃到85℃，完全符合GB/T 19001对工业设备环境适应性的要求，功耗才2W，塞到起重机操作臂的小接线盒里都不用额外加散热。
不过话说回来，选型有两个硬指标，必须卡死，差一点都不行： 第一是推理+预处理总延迟低于控制周期的10%。比如伺服控制的周期是1ms，你的计算必须在100us以内出结果，不然后级控制等数据，直接丢步出事故。 第二是边缘计算模块功耗小于边缘控制器额定功耗的30%。工业控制柜本身空间小，散热条件差，你整一个50W的算力板，夏天柜内温度直接冲到60℃，芯片分分钟降频，原来100ms能跑完的计算，硬生生拖到500ms，结果准不准都白搭。
之前听同行说过一个真事，给盾构机做刀盘磨损预测，选了工业级Jetson Xavier NX，功耗25W，操作柜里没留多余的散热裕量，夏天盾构掘进的时候，刀盘位置的柜内温度快60℃，芯片降频到800MHz，预测直接晚了半秒，刀头磨穿了还没报警，挖破了城市供水管，亏了一百多万。
还有容易漏的，存储。特种设备按《特种设备使用管理规则》要求，必须存至少3个月的原始故障数据，选型的时候eMMC大小一定要留至少50%的冗余，别算着刚好够，实际跑起来系统日志、缓存就能占一半，到时候存不下数据，合规都过不了。
落地过程中你大概率会踩的几个坑
第一个坑，把所有预处理都扔给CPU，算力直接被占满。我自己刚做边缘计算的时候犯过这个错，做振动故障预测，把1024点的中值滤波全放ARM核跑，直接把CPU占了70%，留给模型推理的算力只剩不到20%，帧率根本上不去。后来把滤波逻辑写到板载FPGA的逻辑块里，一下子把CPU占用降到10%，太舒服了。
第二个坑，依赖云端对时，断网就存不了数据。做边缘计算本来就是为了断网也能正常运行，很多人图省事，直接拿云端返回的时间戳当数据标记，一断网，时间不对，所有计算出来的结果都存不进去，直接停摆，一块多钱的工业RTC芯片就能解决，别偷懒。
第三个坑，全模型量化导致准确率掉点太严重。为了在低算力边缘端跑起来，把FP32全改成INT8量化，结果准确率掉了五六个点，原来96%的准确率，现在不到91%，漏检率直接翻一倍。其实完全没必要全量化，把骨干网络量化，检测头输出层保留FP16，准确率掉不到1个点，算力能省一半，这个权衡一定要做。
最后说一个绝大多数人都没注意到的点，一定要做降级模式。要是边缘端算力占满了，或者模型跑崩了，自动切到传统阈值法做基础检测，至少保证设备不停车，能出基本的合格不合格结果，工业现场，稳定永远比精度重要一万倍。
边缘端本地数据计算不是什么玄乎的新概念，也不是大厂炒出来的噱头，是真真切切解决工业智能化落地痛点的方案。不用追高配，不用赶新潮，结合自己的场景需求，选合适的方案，避开那些踩过的坑，就能做出来稳定好用的东西。
