别再让PLC空转:工厂算力资源的踩坑实录与盘活指南

去年帮苏州一家汽车零部件厂做产线升级,对方张嘴就要批20万预算买边缘服务器,等我们把全产线的算力底数摸完,所有人都傻了——23台PLC、8台工控机、3台智能相机的总算力利用率才11%,剩下近9成的算力,全在机柜里空转。

不讲虚的,就讲我们在现场摸爬滚打出来的工厂算力资源盘点、踩坑和实操经验。

先算明白账:你手里的工厂算力资源远不止机房那几台服务器

很多人对工厂算力的认知,还停留在机房里摆的那几台带至强CPU的服务器,觉得算力多少全看服务器买的贵不贵。实际上按照GB/T 33000-2016《企业安全生产标准化基本规范》里对工业自动化节点的定义,所有具备逻辑运算、数据处理能力的工控硬件,都是工厂算力资源的组成部分——从最基础的PLC、运动控制器,到带ISP和NPU的智能工业相机,再到现在集成了边缘计算模块的伺服驱动器、变频器,甚至是装在设备上的智能振动传感器,都算。

离散制造工厂工控节点算力分布统计表
离散制造工厂工控节点算力分布统计表

别上来就买新设备。

我见过太多厂长,一听说要做数字孪生、要做质量追溯,第一反应就是打报告买最贵的边缘计算服务器,结果服务器买回来塞在机房机柜里,跑个简单的数据采集程序,CPU利用率常年不到5%。

说穿了,是连自己手里到底有多少算力都没算明白。

就拿一条常规的年产50万件的机加工产线来说,配的西门子S7-1500 PLC,额定运算能力是1000条二进制指令/微秒,实际用来做逻辑联锁、多轴运动控制的负载,通常只用到额定值的20%-30%——剩下70%的算力,全在空转。还有那种装在外观检测工位的智能工业相机,内置的NPU算力普遍能到2TOPS,实际跑个有无检测、基础尺寸测量的程序,用到的算力连0.3TOPS都不到。

就这,还有人专门给相机配单独的工控机跑检测程序,纯纯的浪费。

最容易栽跟头的地方:算力错配比算力不足的代价大得多

去年那家苏州的汽车零部件厂,一开始的规划是把所有视觉检测算法都集中到新采购的边缘服务器上,觉得这样方便统一管理。结果第一次试产就出了大问题——相机到服务器的工业网线因为车间里的电磁干扰,延迟波动到12ms,原本要求2ms以内响应的尺寸检测环节,精度直接掉了30%,连续筛出来三批不合格的活塞环,光返工成本就快20万。

工厂边缘算力节点延迟测试对比曲线图
工厂边缘算力节点延迟测试对比曲线图

这就是典型的算力错配。

很多人觉得,只要有算力,放在哪跑都一样。根本不是。

按照GB/T 41253-2022《工业互联网平台 边缘计算 总体架构》里的部署要求,硬实时任务(响应周期<1ms)必须放在靠近执行端的节点上——比如PLC、运动控制器、带实时以太网的伺服驱动器,这类任务一旦因为网络波动延迟,轻则产品报废,重则出安全事故。软实时任务(响应周期10-100ms)可以放在就近的边缘网关或者智能相机上,比如图像粗筛、设备温度的异常预警。至于那些非实时任务(响应周期>1s,比如月度生产报表、历史数据上云),才适合集中放在机房的服务器上统一跑。

之前碰过一个做食品包装机的客户,为了省成本,把整条产线的OEE统计程序直接写在S7-1200的PLC里。结果每到整点统计数据的时候,PLC的扫描周期从10ms直接跳到80ms,连带的伺服定位都飘了,包出来的包装袋封口歪歪扭扭,调了半个月都没找到问题根源。最后把OEE程序挪到旁边闲置了快两年的老工控机上,开机跑了半小时,问题立刻解决。

我当时站在客户的车间里,看着那台落了半层灰的工控机,真的想拍桌子——这哪是缺算力啊,这是把好钢全用在刀把上了。

零成本盘活:不用多花一分钱的算力复用实操

很多人一提到盘活算力,就觉得要做复杂的算力调度平台,要花几百万搞软件。其实根本不用,对于绝大多数中小制造工厂来说,只要把现有节点的算力余量用对地方,就能把整体算力利用率提个三四倍。

第一步永远是做连续72小时的算力普查,别光看设备的标称算力,要逐点记录每个工控节点的CPU占用、内存占用、运算负载峰值。很多PLC的标称负载是平均占用率,实际跑满核心程序的时候,峰值也就到40%,剩下的余量完全可以拆出来跑一些轻量的附加任务——比如工位安全联锁信号的冗余校验、工件表面缺陷的初步特征筛选。

这里要提个硬约束,PLC的剩余算力最多只能拿出额定值的20%来跑附加任务,绝对不能挤占核心联锁逻辑、运动控制程序的运算资源。按照GB 5226.1-2019《机械电气安全 机械电气设备 第1部分:通用技术条件》的要求,急停回路的响应时间必须小于50ms,这个是安全红线,绝对不能因为加了附加程序就突破。我之前见过胆子大的工程师,把PLC剩下的60%算力都拿来跑车间的温度数据采集,结果PLC扫描周期直接涨了一倍,冲床的急停信号晚了30ms才触发,差点出人命。

就拿之前那家苏州的厂来说,我们最后做的调整特别简单:把原来集中在服务器上的视觉检测粗筛任务,直接下放到每个工位的智能相机上。相机本身的NPU算力本来就够,先把明显不合格的工件(比如表面有大划痕、尺寸超差超过2mm的)直接筛掉,只把那些临界合格的工件的图像传到服务器上做精细分析。调整完之后,原来闲置的相机算力用到了1.2TOPS,服务器的算力利用率从原来的18%降到了7%,检测精度反而比之前高了——因为粗筛的响应延迟从原来的12ms降到了0.2ms,再也不会因为网络波动丢图像。

不过话说回来,也不是所有的剩余算力都能随便复用。

别信那些销售吹的,要把全工厂的算力都集中到一个大算力池里统一调度。车间里是什么环境?变频器、伺服电机一开机,电磁干扰能让普通网线的丢包率飘到1%,这种环境下搞集中调度,出了生产事故谁负责?

上个月再去那家苏州的厂子,他们现在整条产线的总算力利用率稳定在62%,比一开始的11%翻了快6倍。之前批下来的20万服务器预算省下来,换了两套更高精度的激光尺寸传感器,现在产品的尺寸检测精度从原来的0.02mm提到了0.005mm,客户的投诉率直接降了40%。

其实哪有什么算力不够。

大多时候,只是你没低头看看,那些摆在工位上、塞在机柜里的设备,本来就带着足够的算力,只是被你当成了只会跑固定程序的砖头而已。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:别再让PLC空转:工厂算力资源的踩坑实录与盘活指南
文章链接:https://m.yqhljx.com/list_9/4665.html