如果让我解释 MES 总体架构，我不会先画七八个方框。
我会先拿一张纸，跟着一条产线从开工走到收线。
比如一条散热器装配测试线。早上 8 点，班长领到工单，切换产品型号。操作员扫码上料，锁螺丝机开始跑，点胶设备记录胶量，测试机输出转速、电流和噪音。中间有一次气压不足报警，维修处理后继续生产。晚上班长要看产量、良率、停机时间和异常原因。
MES 架构要接住的，就是这些动作。
我比较怕一种 MES 架构评审：大家围着一张很完整的图点头，但没人能讲清楚一条产品从上线到下线，中间到底会经过哪些人、哪些设备、哪些异常。
真正做现场系统时，图当然要有，但图不能替代走线。
沿着产线走一遍，你会发现系统边界不是按软件模块长出来的，而是按现场动作长出来的。扫码、过站、报工、检测、返修、补录、追溯，每一步都可能把架构里的某个“层”拉到现实里。
一、先把一条线拆成几种对象
一条产线里至少有五类对象。
第一类是设备和控制器。
PLC、CNC、锁螺丝机、点胶机、测试机、扫码枪、视觉检测、包装线。它们产生状态、计数、报警、参数和检测结果。
第二类是生产过程。
工单、工序、派工、过站、报工、返工、入库。这些决定“产品现在走到哪里了”。
第三类是质量和追溯。
SN、批次、原材料、测试结果、上下限、检测图片、返修记录。这些决定“产品出了问题能不能查回去”。
第四类是实时状态。
当前产量、当前节拍、设备运行状态、报警状态、缓存积压、看板刷新时间。
第五类是外部系统。
ERP 给订单和 BOM，WMS 管物料和库存，PLM 管图纸和工艺版本，QMS 管质量标准和客诉。
这些对象混在一起做，系统会很快乱掉。
二、我会按边界拆，而不是按菜单拆
很多 MES 菜单看起来差不多：
工单管理
设备管理
质量管理
追溯管理
看板报表
系统设置但架构不能只按菜单拆。
我更倾向于按边界拆：
设备与控制器
-> 边缘采集层
-> 数据接入与消息层
-> 实时处理层
-> MES 业务层
-> 数据存储层
-> 看板分析与外部系统这个拆法的好处是职责清楚。
设备接入的协议、点位、字节序，不要污染工单服务。
高频设备数据，不要全部压进业务库。
实时看板，不要每次都扫追溯表。
ERP 同步失败，不要影响现场采集。
三、边缘采集层先把现场复杂度挡住
设备现场不会天然整齐。
一条线可能有西门子 PLC，另一条线可能是三菱。测试机可能只会往本地目录写 CSV，扫码枪可能是 TCP 主动推送，视觉设备可能给你一张图片路径和一个 OK/NG。
如果 MES 业务系统直接面对这些差异，后面会越来越难维护。
所以边缘采集层要先把现场差异挡住：
- 读 PLC 点位。
- 处理协议差异。
- 解析数据类型和字节序。
- 做本地缓存。
- 断网后补传。
- 输出标准事件。
比如锁螺丝机的扭矩结果、测试机的转速数据、扫码枪扫到的 SN，最终都应该被整理成业务系统能理解的事件。
四、业务层只处理生产语义
MES 业务层不应该关心 D100 是不是 int32，也不应该关心 FINS 节点号怎么配。
它应该关心：
- 这个工单是否已经开工。
- 这个 SN 是否完成当前工序。
- 测试结果是否合格。
- 设备报警是否影响当前工单。
- 这批产品是否允许入库。
- 某个质量问题影响哪些出货。
业务层吃的是“已经治理过的数据”。
如果业务层每天都在处理原始点位、协议超时、地址偏移和字节序，说明前面的边界没有守住。
五、数据层要从第一天就想清楚
MES 数据最怕一锅炖。
设备温度、压力、转速、电流这类高频数据，适合时序库或独立采集库。
当前设备状态、产线进度、看板数据，适合 Redis 或实时状态表。
工单、过站、质检、追溯、物料批次，适合业务库。
检测图片、测试报告、设备日志，适合文件服务或对象存储。
这不是为了显得架构复杂，而是因为访问方式不一样。
你不会用同一种方式查“某台设备 8 小时温度曲线”和“某个 SN 是否通过终检”。
六、小结
MES 总体架构不是从菜单开始，也不是从框图开始。
它应该从一条产线开始：设备怎么跑，工单怎么切，SN 怎么扫，测试结果怎么来，异常怎么处理，数据怎么追溯。
把这些动作拆清楚，架构边界才会自然。
先从一条线跑通，再谈多产线。
先让现场数据可信，再谈智能分析。
先把现场复杂度和业务系统隔开，再谈平台化。
本系列：
暂无评论