摘要：本文不讲IT圈泛泛而谈的边缘计算概念，只聊机械加工车间落地边缘侧数据计算的真实经验，从场景选择、设备选型到避坑技巧，全是一线项目摸出来的干货，适合打算做产线数字化升级的中级工程师参考。
去年给东莞一家做汽车结构件的冲压车间做数字化改造，踩了大坑。一开始想把所有传感器数据都传到云端算，结果延迟卡到加工精度超差2丝。亏了小十万。现在想起来还肉疼。
说实话，我见过太多数字化项目，钱花了上千万，最后变成了给老板看的大屏，产线工人一点好处没捞着，本质就是核心场景没选对，该用边缘计算的地方非要上云。
为啥机械车间非得搞边缘侧数据计算？别为了数字化而数字化
机械加工里，很多场景对响应速度的要求，比互联网服务苛刻太多。比如在线刀损检测，要求每10ms出一次计算结果，云端来回传输，网络随便抖动一下就是上百毫秒延迟，等你算出刀已经磨废了，工件早就加工完了。
我们算过一笔账，一条24小时运转的冲压线，出一件废件成本是1200块，一天出个三五件，一个月就是十几万，完全扛不住。
边缘侧数据计算的核心，就是把计算任务放在产线本地，就在机床旁边的网关或者工业控制器里算完，只把最终结果传到云端存着。既省了带宽成本，又把延迟压到了几毫秒以内，刚好匹配机械加工的实时控制需求。
不是所有数据都得放边缘算。统计报表、模型训练这些对延迟不敏感的，放云端完全没问题。只有那些和加工过程实时绑定的，比如刀损预警、主轴振动故障检测、冲压力闭环调整，才是边缘侧计算该待的地方。别什么都往边缘塞，白白增加成本。
机械场景下边缘侧数据计算的核心选型权衡
很多工程师选边缘硬件，上来就比核心数、比内存大小，其实完全走错了方向。机械场景的边缘计算，大部分处理的都是振动、压力、位移的时序数据，核心需求就是低延迟、硬实时，不是跑大模型，算力再高没用，满足不了实时性都是白搭。
我们之前就踩过这个坑。一开始选了一款四核x86工业PC，装了Windows系统，算力标称够强，结果系统随机调度延迟最高冲到50ms，完全满足不了我们10ms刷新刀损数据的要求。后来换成了带预empt实时调度的ARM架构工业网关，延迟稳定在1ms以内，成本还降了三分之二。
给大家列几个硬指标，都是卡死的红线，符合行业通用的IEC 61131-2工业控制规范：
第一，实时调度能力必须达标。别选通用桌面系统改的工业设备，一定要选支持硬实时操作系统的，最大调度延迟不能超过2ms，这是做实时计算的基础。
第二，接口兼容性要匹配老车间。大部分工厂老机床的传感器都是RS485、4-20mA模拟量输出，别选那种只有千兆网口的网关，转接口不仅加成本，还会额外增加延迟，得不偿失。
第三，采样能力必须满足计算要求。做振动故障分析的时候，按照奈奎斯特采样定理，要求满足 $f_s \geq 2f_{max}$，如果要测主轴轴承的高频故障，特征频率最高到10kHz，那采样频率至少要20kHz，很多便宜网关采样只有1kHz，根本算不对故障特征，白搭。
最后，防护等级别将就。机床旁边油污大、温度波动大，至少要IP30以上防护、-20℃到70℃的宽温设计，别用桌面级改的设备，用半年积油烧坏，换一次耽误生产，亏的更多。
落地的几个实用技巧，都是踩坑踩出来的
算力冗余留20%就够，别留50%以上。边缘计算本来就是干轻量活的，复杂模型训练放云端，边缘只做推理就好。我们现在用的方案，是云端训练好轻量CNN刀损检测模型，量化压缩到2M以内，边缘网关直接就能跑，推理延迟不到5ms，完全够用，留20%冗余应对突发计算足够了，多了就是浪费钱。
断网容错一定要做。车间网络断个十分二十分是常事，边缘不能一断网就停掉计算，一定要加本地存储，把数据先存在本地，网络恢复了再续传到云端。我们之前做项目，一开始忘了加这个，一次运营商割接断网半小时，出了12个不合格件，老板脸都绿了。后来加了8G的eMMC本地存储，能存7天的原始数据，再也没出过这个问题。
一定要做数据裁剪。边缘别把原始数据都往云端传，只传异常数据和统计结果就行。机械加工95%以上的时间都是正常状态，正常的时候一分钟传一个统计均值就行，只有数据超过阈值了，再把原始数据传上去。这么弄下来，我们那条线一年的带宽费用省了85%，云端存储成本降了90%，太划算。
定期自动校准不能忘。边缘侧的计算精度一般比云端低一点，长时间运行参数容易漂移，一定要做每月一次自动校准，用云端的高精度计算结果对边缘的参数做修正，避免漂移了都不知道，出了问题再救就晚了。
边缘侧数据计算不是什么高大上的玄学，就是给机械车间数字化降本提速的工具。找对场景，选对设备，避开这些常见的坑，就能拿到实打实的收益。我们去年落地的那条冲压线，现在刀损预警准确率98%，废件率降了32%，一年省出来的钱，不到一年就收回了改造投入，比花大价钱搞空架子的数字化强太多。
