国内制造车间数智化改造喊了快十年，八成以上的中小项目栽在了同一个地方：底层底座没打牢。看着好看的大屏跑不起来真实数据，上层应用换了一茬又一茬，数据打通还是做不到。这篇都是我跑现场攒出来的干货，给准备动手的同行提个醒。
为什么说底座不稳，一切数智化都是空中楼阁
三年前我帮东莞一家汽车零配件加工厂收拾烂摊子。老板前一年砸了两百多万上MES，上线半年，OEE统计永远和车间主任报的数对不上，追溯批量质量问题的时候，连哪台机床加工的哪个班次都调不出来。
问题出在哪？所有钱都花在了MES功能和大屏可视化上，没人管底层设备接入的事。车间里12台设备，三个年代四个品牌，协议不统一，采上来的数据丢包率超过15%，老设备根本没预留数字接口，全靠工人每天手工填数据。
这种情况真不是个例。我跑过的二十多个改造项目里，超过六成的企业最开始的需求都是“我要上MES”“我要搞数字孪生”，没人提“我要先搭个能撑住所有应用的底座”。就像盖房子，你连地基都没平，就急着贴瓷砖装吊灯，不塌才怪。
车间数智化基础能力底座建设平台核心设计要点
真要搭底座，核心就两件事：把所有设备连得通，把所有数据理得清。
第一点，统一可扩展的设备接入层必须符合行业通用规范。目前国内执行的是GB/T 40806-2021《智能制造 机器对机器通信 通用要求》和GB/T 33661-2017《智能制造 工业通信网络 行规 通用要求》，所有协议解析必须遵循这个标准，不能自己搞一套私有标准锁死客户。
我之前踩过一个大坑：项目进场才发现，甲方车间有三台2015年出厂的法兰克系统数控车床，采购的采集网关只支持主流的Modbus和OPC UA，不支持法兰克的FOCAS私有协议，厂商说改驱动要收八万，还得等两个月。最后还是用底座平台的可扩展协议框架，我们团队自己花三天写了个驱动插进去，才搞定。太折腾！
第二点，统一数据建模和标准化治理是底座的核心价值。很多人觉得数据采上来就完事了，其实不然。不同设备对“运行状态”的定义不一样，不同应用对“合格产品”的计数方式不一样，最后凑到一起，算出来的OEE能差出20%都不奇怪。
说实话，我见过最离谱的情况，一个装配车间的MES算出来的产能比实际高出三分之一，IT部门查了半个月，最后发现AGV系统把“空载行驶”也算成了设备运行时间，而MES统计运行时间的时候又叠了一次，数字能对才怪。底座就是要把所有这些定义统一，做成标准化的数据资产目录，所有上层应用都从这里拿数，从根源上避免数据打架。
落地时必须做的选型权衡
不过话说回来，不是所有企业都要搞一个大而全的底座。不同规模的车间，需求完全不一样，选型的时候得拎得清。
第一个权衡：部署方式选公有云还是私有化？很多厂商现在拼命推公有云底座，说成本低好维护。对大多数涉及核心制造工艺的车间来说，工艺数据、质量数据都是命根子，带宽不稳定的时候连设备都控不住，选本地私有化部署的边缘底座才是最稳妥的。集团型多车间的，可以搞混合架构，车间本地放底座处理实时数据，云端做跨车间的数据分析，别一刀切。
第二个权衡：成本怎么控？很多中小企业一听到“底座建设”就觉得要几百万，其实完全可以分步走。第一步先把核心生产设备接进来，把基础的OEE计算、质量追溯的数据底座搭好，几十万就能搞定。那些辅助的通风设备、后勤设备，一年用不了几次，完全可以后面再加，没必要一开始就塞进去，纯浪费钱。
第三个权衡：闭源还是开放？一定要选留了二次开发接口的开放底座。我见过好几个项目，厂商交完货，企业IT想改个数据字段，厂商开口就要二十万服务费，不然就不改，硬生生把项目拖死了。开放的底座，哪怕你自己的IT团队水平一般，改点小需求自己就能做，不用被人卡脖子。
车间数智化本来就是慢慢来的事。别赶风口，别玩花活，把底座打牢了，后面上什么应用都能顺顺当当。不然钱花了，活干了，最后留下一堆烂摊子，收拾都收拾不了。
