上周刚从昆山的车间出来，鞋帮上还沾着半干的乳化液印子——就为了那破对接的事熬了两个大夜。很多刚接触车间数字化的工程师觉得，系统对接嘛，写两个API，把数据通上就完事了。哪有那么简单。你蹲在满是切削味的机床旁边待三天，就会发现那些坐在写字楼里画的架构图，十张有九张是飘在空中的。
别拿PLC的实时寄存器当MES的接口源
去年在苏州某底盘零部件厂的项目里，我们一开始为了赶进度，直接把西门子S7-1200的DB块寄存器通过OPC UA通道以100ms的采样周期推给MES。结果在一次机床换型时，工艺工程师把DB块的起始地址从DB100改到了DB200，MES那边直接把原本对应“加工完成计数”的地址读成了“主轴转速”。当天的OEE统计直接崩到了32%——要知道之前的平均OEE是87%。
别这么干。坑死你。
PLC的寄存器是给机床自己用的，地址分配、保持性、触发逻辑全是跟着工艺走的，根本不具备对外接口的稳定性。我们后来补了一台边缘采集网关，专门做信号防抖锁存：只有当“加工完成”的上升沿持续超过200ms，才触发一次数据上传，把当前的工件号、实际加工时长、当前刀具寿命存在网关的本地SQLite缓存里，等网络稳定了再批量推给MES。这才符合GB/T 33916-2017《数字化车间 通用技术要求》里提到的“数据采集应具备断点续传、异常过滤能力”的要求。
之前有个刚毕业的小伙子跟我说，他觉得OPC UA的采样周期设得越快越好，设成10ms。结果车间里的22kW变频器一启动，电磁干扰直接把工业以太网的通道占满，MES那边收到的数据包全是乱码。他蹲在机房里抓了三天包才找到原因——就因为他没在网关里开“信号变化触发上报”，代替了无意义的高频采样。高频采样除了占带宽，半毛钱用没有。
线边库对接，别只同步库存数，要算物料移动的时间差
对接完设备端，接下来就是最容易扯皮的线边库部分。很多人的对接逻辑很简单：WMS里有多少库存，直接同步给MES就行。听着没毛病对吧？
我上次在上海的一家电机厂就踩过这个坑。MES显示绕线工位的漆包线还有120卷库存，排产计划直接排了120卷的加工任务。结果线边库的货架上其实只有18卷，剩下的102卷还在AGV的运输路上——从中央仓库到线边库的路径有三个直角拐角，遇到卸货的叉车还要让行，平均运输时长14分钟。就因为等料，机床空转了1小时40分钟，排产班长追着我骂了一上午，说我害他拿不到当月的绩效奖。
后来我们改了对接逻辑：WMS推给MES的库存数据，要拆成三个独立字段——在库可领用数量、在途待入数量、物料运输提前期。而且要给排产逻辑加一个安全缓冲：比如漆包线的单件加工时长是3.2分钟，我们就按15分钟的缓冲时间，算出来需要预留5卷的安全库存，这个值不是拍脑袋定的，是连续跑了7天的现场数据摸出来的。
还有个细节容易被忽略：车间里的金属切削液飞溅、电磁干扰，会让普通的RFID标签读取率掉得厉害。我们之前用的普通超高频RFID标签，在机床旁边的读取率只有81%，后来给每个标签加了个薄铝制屏蔽罩，读取率直接拉到99.2%——这个成本一个标签才3块钱，比因为读错数停线的损失便宜太多了。
对接完不是终点，是现场问题排查的起点
很多人觉得，接口通了，数据能传了，项目就完事了。大错特错。
我们之前在常州的一家齿轮厂，对接完过了整整一个月，MES统计的月度产量比车间实际盘点的数多了12%。查了半天才发现：有台滚齿机的“加工完成”信号，因为刀具崩碎的时候震动太大，误触发了47次上升沿，网关当时没做防抖阈值，直接把这些误触发的信号全当有效数据推给MES了。
真的，对接的时候一定要把全链路日志溯源做足。每个接口调用的时间、传输的参数、返回的状态、经过的网关节点，全部存在本地的日志服务器里，至少存3个月。不然出了问题，你连是PLC的锅、网关的锅、还是MES的锅都分不清。
还有个选型的权衡可以提一下：很多人纠结对接的时候用TCP还是UDP。其实关键的业务数据，比如加工完成计数、物料领用记录，用TCP就好，重传机制能保证数据不丢；但实时性要求高的信号，比如机床的急停状态、安全门开关信号，就用UDP，但是要给每个数据包加个序号，丢包了就在下一个周期补传——毕竟总不能因为网络卡了两秒，急停信号没传到MES，就把人吓个半死。
我现在做对接项目，从来不会一开始就写接口文档。先蹲在车间里待三天，跟着班组上两个中班，把每个工件从上线到下线的流程摸得门清，知道哪个数据是真的要用来算绩效的，哪个数据是给领导看的摆设。不然写出来的接口，全是脱离现场的花架子。
车间系统对接从来不是坐在写字楼里敲代码的活。你得沾过乳化液，听过机床的切削噪音，见过班组因为等料急得跳脚的样子，做出来的对接逻辑才是真的能用的。别总拿着那套互联网的API思路套工业场景——车间里的事，从来都不是数据通了就完事的。
