两化融合实践中的“语义断层”：为什么数据通了，排产还是靠微信群

上周在南京江北新区一家做伺服电机的厂里，我盯着他们的排产看板看了十分钟——看板上贴着三张A4纸，分别是ERP导出的工单、MES里的工序进度、以及微信群里的“紧急插单”。车间主任老周说，系统都上了，两化融合贯标也过了，但每天早会还是靠吼。这场景你熟不熟？

说实话，我当时有点懊恼。因为三年前我参与过这个厂的MES选型，当时拍着胸脯说“数据打通就顺了”。结果呢？数据是通了，从ERP到MES的接口跑了三年，没出过大故障——可业务逻辑还是各说各话。ERP里的“工单完成”指财务结算，MES里的“工序完成”指物理加工，两者之间差着质检、返修、报废三个状态。这些状态在系统里没有统一的语义，于是计划员只能手动补Excel。

这引出一个被两化融合实践反复踩坑的问题：接口连通不等于业务语义连通。很多项目把“系统集成”当成目标，用ESB或API网关把几十个系统连起来，却没人定义“一个工单的生命周期”在OT和IT侧到底怎么表达。ISA-95标准给了层级模型，但落地时企业往往跳过第2层（制造运营管理）的语义建模，直接在第3层（ERP）和第1层（PLC）之间拉数据。结果就是数据管道很粗，信息含量很低。

数据通了，为什么排产还是靠微信群？

因为排产的约束条件不在数据库里。老周厂里换型时间取决于模具预热和首件检验，这两个时间在MES里是固定值，实际却随环境温度、操作工熟练度波动。ERP的排产算法假设这些是常数，算出来的计划当然不可执行。计划员只好用微信群收集“今天模具预热多花了四十分钟”这类非结构化信息，手动调整。这不是技术问题，是两化融合实践中对“隐性知识显性化”的投入不足。

怎么破？我们后来做了一件事：在压铸机旁加了一个带按钮的工位终端，操作工换型时按一下“开始预热”，再按一下“预热完成”，系统自动记录实际时长并回写到MES的工艺参数表。三个月后，排产算法的换型时间从固定值变成基于历史分布的预测值。效果？计划达成率从72%提到86%。但这个方案有个前提：操作工愿意按按钮。我们给每个按按钮的班组加了绩效系数——数字化必须配套激励，否则就是给工人增加负担。

OT的脾气，IT的规矩：协议转换不是插个网关就完事

两化融合实践绕不开OT与IT的协议栈差异。IT侧习惯TCP/IP、RESTful、JSON，OT侧还在跑Modbus RTU、Profibus、甚至4-20mA模拟量。很多集成商的做法是加一台协议转换网关，把Modbus映射成OPC UA，然后扔给MES。听起来合理，对吧？但坑在实时性和数据质量上。Modbus轮询周期设成500ms，网关缓存一开，PLC里的瞬时故障（比如传感器抖动）就被平滑掉了，MES看到的永远是“正常”。等设备真停了，MES才报异常——晚了。

更麻烦的是OT侧的数据语义是设备厂商定义的私有地址。比如某品牌注塑机的“锁模力”在寄存器40021，另一个品牌在40055，单位还不同（kN vs ton）。网关只做协议转换，不做语义映射，MES就得为每台设备写解析脚本。我见过一个厂，MES里有137个设备解析脚本，维护成本高到没人敢升级。这算是两化融合实践里典型的“技术债”。

我的建议是：在边缘侧做统一信息模型，而不是在MES侧做适配。用OPC UA的信息建模能力，把每类设备抽象成“设备类型+属性集”，网关负责把私有地址映射到标准属性。这样MES只认标准模型。前提是设备厂商愿意配合提供UA companion specification——很多国产中小设备厂商做不到。那就退一步，用边缘计算节点跑一个轻量级的数据字典服务，至少把单位、量程、采样频率统一了。别指望一步到位。

融合的边界：哪些工序不该数字化？

这是我最想吐槽的地方。两化融合实践被一些咨询机构包装成“全流程数字化”，好像不把每道工序都上系统就不算融合。但有些工序的数字化成本远高于收益。比如某精密装配车间的手工研磨工序，依赖老师傅的手感，数字化需要加装力传感器、视觉检测、机器学习模型——投入两百万，良率提升不到3%。而同期把研磨前的清洗工序自动化，投入三十万，良率提升8%。数字化优先级应该按“瓶颈工序的边际收益”排序，而不是按“技术先进性”。

不过话说回来，有些工序现在不该数字化，不代表永远不该。传感器成本每年降，模型训练门槛也在降。关键是建立可扩展的数据采集架构——比如在关键工位预留IO-Link接口，先不接传感器，等业务需要时插上就能用。这叫“留接口，不预埋系统”。比一次性上全套便宜得多。

一个反例：工业大脑为什么变成了“工业大坑”

2019年我参与评审过一个项目：某大型流程企业花八百万买了某云厂商的“工业大脑”，目标是用AI优化反应釜温度曲线。项目上线六个月，AI推荐的温度曲线被操作工拒绝执行——因为AI模型训练用的是历史DCS数据，而历史数据里包含了大量“人工干预”的样本，模型学到了“操作工喜欢在下午三点调低温度”这种伪相关。更致命的是，AI推荐的曲线在仿真里能降能耗5%，但实际执行时因为原料批次波动，反而导致副产物超标。

这个案例说明：两化融合实践中的算法应用必须考虑OT侧的鲁棒性和可解释性。AI模型在IT环境里可以容忍5%的误差，但在反应釜里，5%的误差意味着安全事故。后来项目组改成“AI推荐+操作工确认”的半自动模式，把模型输出限制在安全操作窗口内，才勉强跑通。但八百万的预算已经花完了，ROI算不过来。这算是交学费。

说点实在的

两化融合实践走到今天，技术工具已经足够丰富——MES、SCADA、数据中台、边缘网关、低代码平台。但真正卡住企业的往往不是工具，而是组织内对“什么是好数据”缺乏共识。质量部门要的是追溯粒度到批次，生产部门要的是实时性到秒级，财务部门要的是成本归集到工单。这三个需求在数据模型上可能冲突——批次追溯要求数据不可变，实时性要求数据流式处理，成本归集要求数据关联财务科目。没有哪个平台能自动解决这个冲突，只能靠人坐下来对齐语义。

所以我的观点是：两化融合实践的成熟标志，不是上了多少系统，而是业务部门能用自己的语言描述数据需求，IT部门能听懂并翻译成技术方案。至于“融合”还是“缝合”，区别就在这儿。别急着上云，先把工位上的Excel干掉——用最土的办法，让数据在源头就带着业务语义。这比什么都管用。