雾计算（工业）：别再把它当云计算的附庸，车间里已经用上了

去年跑一家汽配厂，车间主任拉着我看他们新上的预测性维护系统。我以为是用的云端AI——结果他摆摆手，指了指角落里一个不起眼的铁盒子，说：“就靠这个，毫秒级响应，云那边根本来不及。” 那盒子，就是雾计算节点。

说实话，雾计算（工业）这个词，听起来总有点不明觉厉。五六年前刚冒出来的时候，不少人觉得它就是个营销概念，云计算不够用了再搞个“雾”来凑。可这几年，尤其是工业圈子里，它真不是飘在PPT上了。

云够不着的地方，雾来填

工业现场最头疼啥？延迟。振动传感器每秒采几千个点，等数据传到千里之外的云端分析完再下发指令，轴承早就烧了。雾计算干的，就是在本地把数据消化了——靠近设备的那一层，或者说“边缘以上、云以下”的中间地带。

别跟我扯那些三层架构图。你只要记住：PLC和传感器是第一线，SCADA/MES是中间，ERP/云端在最上面。雾计算节点就在SCADA那一层，或者跟网关集成在一起，具备计算、存储和网络能力，能跑轻量级分析模型。💡 它不依赖云端决策，自己就能做快速响应。

有人会问：这不就是边缘计算吗？问得好。

边缘计算 vs 雾计算，烦不烦？

业内吵了好几年了。我直接说我的看法——边缘计算强调“点”，雾计算强调“域”。边缘节点处理单台设备或单一产线的数据，雾节点则把多个边缘节点联结起来，做跨设备、跨区域的协同。比如一个冲压车间，三台压机各带边缘网关，数据汇到车间级的雾节点，做工艺参数联动优化。这么干，既保了实时性，又有了局部智能。

不过话说回来，现在很多厂商把两者混着叫，你也别太较真。关键看部署位置和协作关系。❗ 见过最离谱的——某MES厂商把自家的服务器加了个雾计算标签，纯属蹭热点。真正落地的，还得看通信协议和架构。

车间里到底怎么用？说个真事儿

那个汽配厂的案例还没讲完。他们给机器人减速机装了振动和温度传感器，边缘网关采集后发给雾节点，上面跑了一个训练好的LSTM轻量模型。一旦振动频谱出现异常尖峰——雾节点10毫秒内触发停机信号，并通知MES。同时，它把预处理后的特征数据异步传到云端做深度训练。半年下来，非计划停机砍了七成。

这就回答了那个经典问题：

问：数据都放在本地分析，还要云端干嘛？

答：云端是大脑，雾节点是小脑。小脑管身体平衡（毫秒级），大脑负责长期规划（模型迭代、跨厂区分析）。而且，雾节点还能做数据过滤，只把有价值的摘要传给云端，省带宽、省成本。✅ 不少现场用的OPC UA over TSN，就是靠雾节点做协议转换和数据聚合。

不过，别以为上个雾计算就万事大吉。几个坑得提：

协议不统一：有的老设备连Modbus都没整明白，雾节点就得充当翻译官，开发量不小。
安全：雾节点贴近现场，一旦被攻击，直接停线。得做设备认证和流量隔离。
运维：雾节点散在车间，不像云端集中，更新模型、打补丁都得专人跑现场，或者用OTA方式。

问与答：解决你的实在疑虑

再聊几个实操中经常被问到的问题，可能你也在犯嘀咕。

问：我们厂已经用了工业云平台，还有必要上雾计算吗？

答：看你的痛点是啥。如果你对实时控制没要求，只是报表分析，那现有的上云方案够用。但凡是涉及设备联动、快速保护、闭环控制——比如焊接机器人根据电流反馈实时调整参数，50毫秒以上的延迟就废了。这时候必须在车间侧部署雾节点，把闭环链路缩短。另外，如果联网不稳定，雾节点还能做离线自治，网断了照样跑。

问：中小厂子，预算紧，雾计算投入大不大？

答：其实现在不少工业网关都集成雾计算能力了，价格没那么吓人。你可以先从一条关键产线试点，用个工控机加开源平台（比如EdgeX Foundry）搭一套，跑一两个关键模型。💡 别一上来就全车间铺开，步子太大容易扯着。还有个省钱招——跟云厂商谈混合方案，本地节点按需订阅，授权费能降不少。

不过话得说回来，这几年国内做工业雾计算的创业公司多了起来，方案成熟度比五年前好太多。以前是概念满天飞，现在至少能看到真东西了。

最后唠叨一句：雾计算（工业）不是替代云，也不是替代边缘，它就是填补架构空白的中间层。就像车间里那个不起眼的铁盒子，没人注意，但少它不行。

（注：文章结合实际走访和行业报告，数据脱敏处理。）