做 MES，不要先画大图，先去现场看一圈

我以前也觉得，做 MES 架构，第一步应该先画一张完整的大图。

设备层、采集层、消息层、业务层、数据层、看板层，再把 ERP、WMS、PLM、QMS 接在旁边。图画出来以后，看起来很稳，很像一个系统该有的样子。

后来才发现，MES 最难的部分，往往不在图上。

它藏在产线边上。

班长说今天产量对不上，实际做了 680 件，看板只显示 663 件。电气工程师说 PLC 点位没问题，软件工程师看日志也没报错。最后查到设备侧才发现，MES 读的不是“当前工单产量”，而是设备累计计数。换工单时设备没有清零，系统也没有按工单开始时间做差值。

架构图没有错，但它没有告诉你这个坑。

我后来发现，看一个 MES 项目靠不靠谱，不能只看会议室里的方案。

要去线边站一会儿，看操作工怎么扫码，班长怎么催产量，设备工程师怎么判断停机，实施同事怎么解释一个“系统卡住了”的反馈。

很多架构问题，到了现场会变成很具体的小事：扫码枪扫不上、工位切换没同步、PLC 点位解释不一致、网络一抖数据就补不上。

这些小事才是 MES 真正的入口。

一、MES 不是先有系统，再接现场

很多后台系统可以先把表和页面做出来，再慢慢补流程。

MES 不太一样。

它要贴着现场跑。现场设备怎么动作，工人怎么扫码，测试机怎么出结果，异常怎么处理，换线怎么切产品型号，这些细节会反过来决定系统怎么设计。

以一个电脑散热器工厂为例，听起来只是铝材、铜材、热管、风扇、焊接、装配、测试、包装。

但落到 MES 里，会变成一连串具体问题：

CNC 能不能联网？读的是西门子、三菱、欧姆龙，还是国产 PLC？
焊接设备有没有温度曲线？曲线要不要追溯到 SN？
风扇测试机是主动推 TCP 消息，还是只在本地生成 CSV？
扫码枪扫到 SN 后，谁来确认它属于当前工单？
视觉检测图片放本地工控机，还是上传文件服务？
设备报警是一组报警码，还是只有一个报警状态点？
换工单时，PLC 计数点位会不会清零？
现场断网十分钟，测试结果要不要补传？

这些问题如果没弄清楚，MES 很容易从“生产执行系统”变成“人工补录系统”。

二、先跟着一件产品走完一遍

我更倾向于先选一条产线，跟着一件产品走完。

比如一条风扇模组装配线，大概会经历：

上料
  -> 扫码绑定 SN
  -> 锁螺丝
  -> 点胶
  -> 外观检测
  -> 转速 / 电流 / 噪音测试
  -> 包装

站在系统角度，这不是几个工序名称，而是一条数据链。

扫码时，要知道 SN、工单、产品型号、工序和工位。

锁螺丝时，要知道扭矩是否合格，设备编号是什么，结果对应哪个 SN。

测试时，要保存转速、电流、噪音、上下限、OK/NG、测试设备和测试时间。

包装时，要知道 SN 属于哪个箱号、托盘号，后续出了问题能不能反查。

如果这条链路串不起来，后面谈 OEE、质量追溯、实时看板、异常分析，都会变得很虚。

三、现场会逼你重新理解架构

在会议室里看，MES 可能是几个模块：

工单
报工
质检
设备
追溯
看板
报表

到现场以后，它会变成另一种问题：

设备点位谁维护？
扫码漏扫怎么办？
测试机重测后保留哪一次结果？
设备累计计数怎么换算成当前工单产量？
断网期间的数据放哪里？
PLC 点位变更谁通知软件？
MES 能不能写 PLC 控制点位？

这些问题不够“架构”，但它们决定系统能不能在车间里活下来。

所以这个系列不会按 MES 功能百科来写。

我更想按现场路径写。

四、这个系列会怎么展开

第一篇讲总体架构，但不是先画大图，而是从一条产线拆开：设备、扫码、工单、测试、质量、看板和外部系统，分别应该放在哪个边界里。

第二篇讲边缘采集层。重点不是“采集层很重要”，而是西门子、三菱、欧姆龙、台达、汇川、测试机、扫码枪这些现场设备，怎么通过点位表、协议和边缘 Agent 进入统一模型。

第三篇讲设备数据链路。一条温度数据、一个报警、一条测试结果，最后应该去 Redis、时序库、业务库，还是文件存储。

第四篇讲 7x24 稳定运行。断网、重连、补传、幂等、设备离线误判、消息积压，这些都是 MES 的日常。

第五篇讲质量追溯。一个 NG 产品出来以后，系统要能倒查工单、SN、设备、人员、材料批次、工艺参数和测试结果。

第六篇讲部署演进。小工厂先打通一条线，中型工厂补稳定性，多基地再谈统一平台和数据治理。

第七篇讲 .NET 落地。Web API 只是其中一部分，Worker、边缘 Agent、消息队列、Redis、时序库和文件服务都要放到合适的位置。

第八篇专门讲控制器对接。西门子、三菱、欧姆龙、台达、汇川怎么接，地址、字节序、读写权限和现场联调怎么处理。

五、我希望这组文章有现场味

这组文章不是为了证明 MES 架构可以画得多完整。

它更想回答一些具体问题：

为什么看板产量会不准？
为什么点位表比代码更重要？
为什么业务库不能承接所有设备数据？
为什么断网补传一定要做幂等？
为什么追溯不是最后查报表，而是生产时就要绑定？
为什么 MES 默认应该少写 PLC，多读 PLC？

如果读完以后，读者能感觉到：MES 不是几个页面，而是一个贴着产线跑的系统。那这个系列就有意义。

六、小结

做 MES，先不要急着堆系统名词。

先去现场看一圈。

看设备怎么跑，看工人怎么扫，看测试结果怎么出来，看班长怎么判断进度，看电气工程师怎么维护点位，看网络断了以后现场怎么办。

这些东西看清楚了，再回头设计架构，很多取舍会自然很多。

本系列：