雾计算（工业）：当车间里每一毫秒都算数，凭什么还指望云端？

上个月，在宁波的一家注塑工厂，老板指着设备对我说：“我这机器，每次停机再启动，废品率就飙升。后来发现，是数据传回阿里云再回来的那200毫秒，让温控反应慢了半拍。” —— 就200毫秒！损失每年几十万。他后来怎么解决的？没上什么大平台，就在车间角落加了台“不起眼”的工业计算机，运行雾计算节点。

雾计算不是云的山寨版

很多人一听“雾”，就觉得是云计算的廉价替代。大错特错。雾计算（工业）这个术语，最早是思科在2014年提出的，但真正在工业里生根，是最近三四年的事。为什么？因为工业现场的确定性需求太变态了。一个运动控制器，必须在1毫秒内响应，你敢把指令绕道公有云？

说实话，我第一次接触雾计算架构是在一家汽车焊接车间。几百台库卡机器人，传感器每秒产生数万条数据。如果全送云端分析，带宽先崩，延迟更别提。他们做了什么？在每一条产线旁部署了雾计算网关——不是什么高级服务器，就是加固型工控机，运行着轻量化的数据分析模型。它只把异常事件上传，比如焊点温度偏离标准差，而海量的正常数据，根本不出车间。这叫“就地消化”。

这让我想起一个老自动化工程师的吐槽：“我们搞PLC的时候，就已经在雾里了，只是你们IT人非要换个名字。” 话糙理不糙。PLC、DCS本质上就是最原始的雾计算节点，只不过现在加上了通用计算能力和IP通信。

“比边缘多一步，比云快十倍”——到底怎么定义？

当谈边缘计算和雾计算，界限确实模糊。根据OpenFog联盟（现在并入IEEE）的参考架构，雾计算强调的是从云端到物端的连续计算层次，而边缘计算更聚焦在终端设备或网关上。你可以这样理解：边缘是触角，雾是局部大脑，云是全局大脑。

但工业场景下，这个“局部大脑”往往要干很多脏活累活。比如协议转换——底下设备说Modbus TCP，上面MES系统要OPC UA，谁来翻译？雾节点。再比如，当网络中断时，生产不能停。雾计算必须能离线自治，缓存数据，等网络恢复后同步，同时保证工艺参数不漂移。这一点，纯边缘设备往往做不到，因为它算力不够跑完整的机理模型。

去年我参与过一个锂电池涂布机改造项目，就栽过跟头。最初方案是边缘侧直接做厚度PID调节，但电极材料特性随批次变化，固定参数不行。后来我们在车间级加了一个雾服务器，在线训练小规模神经网络，动态调整边缘的PID参数。效果？横向厚度变异系数从1.2%降到了0.3%。这个案例里，雾计算做了边缘做不了的跨设备协同和模型自学习。

答：完全不是。我常跟团队讲，PLC的确定性实时控制无可替代，雾计算擅长的是非确定性的智能化任务，比如预测性维护、质量追溯、能效优化。你可以把雾节点想象成一个“贴在产线上的AI助手”，它默默地看着PLC和传感器，发现问题就调参，但不会直接插手安全联锁。实际部署时，我们往往通过边缘网关桥接OT和IT，雾节点运行在更上层，比如像Docker容器里的微服务。

什么时候该用雾？三个让你无法拒绝的信号

大多数工厂其实不需要雾计算。如果你只是采集些OEE数据做看板，边缘网关上传云就够了。但出现以下情况，雾可能救你的命：

1. 闭环控制延迟要求低于50毫秒——比如高速视觉检测剔除系统，火花塞打火时刻调整。这时云端指挥来不及，连本地5G MEC可能都勉强，需要更近的雾节点。

2. 数据量太大，但价值稀疏——比如振动频谱分析。一台风机每秒采集10KHz的高频数据，全上传的话，工业网络直接被堵死。雾计算在本地做FFT，只上传特征频率和报警。

3. 多设备协同决策——典型如AGV集群调度。每台AGV有自己的边缘避障，但全局路径规划和交通管制，需要一个车间级的雾调度器，它要融合生产计划、设备状态、电池剩余寿命，做出最优派发。这个智能体不能离现场太远。

当然，坑也不少。最大的坑是运维复杂性。原本车间里没几个IT设备，现在多了几个雾节点，谁管理？IT和OT部门打架我见得太多。所以现在很多厂商推“超融合一体机”，把虚拟化、网络、存储、还有工业协议栈都打包好，插电即用。像华为的Atlas 500、西门子的Industrial Edge Management，都是这个思路✅。

答：理论上可以，但工业环境高温、粉尘、振动，普通服务器撑不过半年。我曾在东莞一家铸造厂见过，他们用一台戴尔R740跑雾计算，结果三个月后内存金手指氧化，死机不断。后来换成IP65防护的无风扇工业电脑，问题消失。所以硬件上必须考虑宽温、抗腐蚀、冗余电源。此外，如果只是轻量级应用，比如数据过滤和协议转换，有些网关已经内置了容器引擎，能跑简单的雾功能，成本低很多。但要做像样的大数据分析，最好还是上具备GPU加速的工业计算机💡。

从标准到落地——2024年的几个新变化

我注意到，自从IEC 62264-3标准扩展了制造运营活动的功能层级，雾计算被更明确地定位在“监控与监控”与“自动化”之间。另外，OPC基金会去年发布了OPC UA over TSN的规范，这为雾节点之间的确定性通信铺平了道路。这意味着什么？不同厂商的雾节点可以实时交换控制级数据，而不是仅仅交换信息。这是一个巨大的进步，它让分布式实时控制成为可能。

还有一个趋势：AI在雾侧推理的轻量化。TensorFlow Lite、ONNX Runtime等框架已经能很好地裁剪模型，跑在ARM架构的低功耗设备上。我们团队最近测试了在树莓派4（工业宽温版本）上运行基于振动信号的轴承劣化预测，模型只有500KB，每推理一次耗时8毫秒，准确率98%。这种成本，让很多中小企业有了尝试的底气。

不过话说回来，雾计算并不是银弹。有的场景下，一个强大的边缘控制器就够了；有时直接把数据拉到私有云更简单。我提倡“合适的算力放在合适的地方”。工业的多样性决定了没有一统天下的架构。但至少，在追求极致的质量、效率、柔性的路上，雾这层薄薄的“计算层”，确实成了一块不可忽视的基石。

最后分享一个细节：去年德国汉诺威工博会上，我看到多家传感器厂商直接推出“雾就绪”传感器，自带OPC UA Pub/Sub和MQTT，可以直接与雾节点对等通信。这表明，产业链已经在向前整合。对于我们这些搞工业的人来说，是时候重新审视自己的网络拓扑了。