简介：这是一套面向制造业信息化开发者与MES学习者的加工装配模拟系统源码资料，基于Visual Studio 2010与SQLServer2008R2、.NET 4.0开发，适合希望理解MES核心业务逻辑与实现方式的中级开发者参考。系统分为服务端与客户端两大部分：服务端涵盖产品、物料、工序、工位、工艺路线等基础档案，加工与装配计划管理，加工及装配实时看板，数据初始化、标签初始化工具与实时监听服务；客户端则实现加工与装配的过程控制、搬运过程控制以及质量异常处理，核心逻辑通过数据库存储过程实现。资源包共445个文件，约10MB，以cs源码、dll程序集、resx与resources资源文件、txt说明、config配置、exe可执行程序及png、jpg界面素材为主，另含mdf与ldf数据库文件、sln解决方案和docx设计说明书，DB文件夹附加即可运行，Doc文件夹提供《SimpleMES加工装配模拟系统》设计说明书。目前已有557人学习，便于读者快速搭建模拟环境、研读源码结构与存储过程设计，掌握MES加工装配流程的落地思路。
1. 从一张工单跑不完说起：SimpleMES 加工装配系统到底解决什么问题
很多中小制造企业的车间里，工单从 ERP 下发之后就开始“失联”：纸质流转卡被油污糊住、装配缺料靠班组长吼、返工返修记录写在白板上一擦就没。SimpleMES 这类轻量级 MES 加工装配系统，瞄准的正是这个断层——它不追求覆盖排产、供应链、财务全链路，而是把“工单下发→工序报工→装配追溯→返修闭环”这条最短路径跑通。你如果是工厂 IT、自动化工程师，或者正在做 mes系统 选型的生产负责人，这套思路能让你用一台工控机加一个浏览器，在两周内看到真实产线数据。它适合离散制造的加工装配场景，不适合流程行业，也不适合想一步到位上全模块的大集团。核心价值就一句话：让每一张工单的每一个工序，都有时间戳、有人、有结果。
2. SimpleMES 的加工装配数据模型：工单、工序与装配关系怎么建
2.1 为什么加工装配场景不能照搬 ERP 的 BOM 结构
ERP 的 BOM 是面向采购和成本的，它告诉你一台产品需要哪些料，但不告诉你这些料在哪个工位、以什么顺序装上去。SimpleMES 加工装配系统的数据模型必须多一层“工序-物料绑定”：同一颗螺丝，在工位 A 是拧紧动作，在工位 B 可能是返修更换件。常见做法是把工单（WorkOrder）作为主实体，下面挂工序实例（OperationInstance），每个工序实例再挂物料消耗记录（MaterialConsumption）。这样返修时你不需要改 BOM，只需要在对应工序实例上追加一条返修记录，原始装配关系不动。这个设计的好处是追溯链完整：扫一个成品条码，能反查出它经过的每一道工序、每个工位的操作员、每颗关键件的批次号。
我一般会建议在工序实例上加三个字段：op_seq（工序序号）、station_code（工位编码）、op_status（待加工/加工中/已完成/返修中）。op_status的状态机要严格，不允许从“待加工”直接跳到“已完成”，必须经过“加工中”，否则报工时间无法计算。物料消耗记录里则要有material_batch和qty，返修换件时qty可以为负，表示拆下旧件。
2.2 建表脚本：五张核心表撑起加工装配追溯
下面这段 SQL 是 SimpleMES 加工装配系统的最小可用表结构，跑在 MySQL 8.0 上。注意work_order和operation_instance之间是一对多，operation_instance和material_consumption也是一对多。
-- 工单主表 CREATE TABLE work_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, wo_no VARCHAR(32) NOT NULL UNIQUE COMMENT '工单号', product_code VARCHAR(64) NOT NULL COMMENT '产品编码', plan_qty INT NOT NULL DEFAULT 0 COMMENT '计划数量', done_qty INT NOT NULL DEFAULT 0 COMMENT '完成数量', wo_status TINYINT NOT NULL DEFAULT 0 COMMENT '0待产 1生产中 2完工 3关闭', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_wo_no (wo_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 工序实例表 CREATE TABLE operation_instance ( id BIGINT PRIMARY KEY AUTO_INCREMENT, wo_id BIGINT NOT NULL, op_seq INT NOT NULL COMMENT '工序序号，从10开始留间隔', op_name VARCHAR(64) NOT NULL COMMENT '工序名称', station_code VARCHAR(32) NOT NULL COMMENT '工位编码', op_status TINYINT NOT NULL DEFAULT 0 COMMENT '0待加工 1加工中 2已完成 3返修中', operator_id VARCHAR(32) DEFAULT NULL, start_time DATETIME DEFAULT NULL, end_time DATETIME DEFAULT NULL, FOREIGN KEY (wo_id) REFERENCES work_order(id), INDEX idx_wo_op (wo_id, op_seq) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 物料消耗记录 CREATE TABLE material_consumption ( id BIGINT PRIMARY KEY AUTO_INCREMENT, op_inst_id BIGINT NOT NULL, material_code VARCHAR(64) NOT NULL, material_batch VARCHAR(64) DEFAULT NULL COMMENT '批次号，追溯用', qty DECIMAL(10,3) NOT NULL DEFAULT 0 COMMENT '正数消耗，负数退料/换件', scan_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (op_inst_id) REFERENCES operation_instance(id), INDEX idx_op_inst (op_inst_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 返修记录表 CREATE TABLE rework_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, op_inst_id BIGINT NOT NULL, rework_reason VARCHAR(255) NOT NULL, rework_action VARCHAR(255) NOT NULL COMMENT '返修动作描述', old_batch VARCHAR(64) DEFAULT NULL, new_batch VARCHAR(64) DEFAULT NULL, operator_id VARCHAR(32) NOT NULL, rework_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (op_inst_id) REFERENCES operation_instance(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 产品序列号追溯表 CREATE TABLE product_sn_trace ( id BIGINT PRIMARY KEY AUTO_INCREMENT, sn VARCHAR(64) NOT NULL UNIQUE COMMENT '成品序列号', wo_id BIGINT NOT NULL, current_op_seq INT NOT NULL DEFAULT 0, sn_status TINYINT NOT NULL DEFAULT 0 COMMENT '0在制 1完工 2返修中 3报废', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_sn (sn) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;逻辑说明：operation_instance里的op_seq用 10、20、30 这样的间隔，是为了后续插入临时工序时不至于全表改序号。material_consumption.qty允许负数，这是返修换件场景的关键设计——拆下旧件记 -1，装上新件记 +1，净消耗不变但批次追溯完整。product_sn_trace.current_op_seq记录当前走到哪道工序，扫 SN 就能定位。
参数说明：wo_status和op_status的枚举值不要用字符串，用 TINYINT 省空间且索引快。material_batch建索引，因为追溯查询最频繁的就是“这批次的料装到了哪些 SN 上”。字符集统一 utf8mb4，避免车间录入特殊符号时乱码。
2.3 工单下发与工序报工的接口约定
SimpleMES 加工装配系统对外一般暴露 REST 接口，内部用 WebService 的老系统也不少。工单下发接口接收 ERP 传来的 JSON，核心字段是wo_no、product_code、plan_qty和工序列表。工序列表里每道工序要有op_seq、op_name、station_code。报工接口则接收sn、op_seq、operator_id和scan_time。
{ "wo_no": "WO20250101-001", "product_code": "P-8801", "plan_qty": 100, "operations": [ {"op_seq": 10, "op_name": "底板装配", "station_code": "ST-01"}, {"op_seq": 20, "op_name": "水冷板安装", "station_code": "ST-02"}, {"op_seq": 30, "op_name": "气密测试", "station_code": "ST-03"} ] }报工接口收到后，先根据sn查product_sn_trace，校验current_op_seq是否等于请求的op_seq，不等就拒绝，防止跳站。然后更新operation_instance的op_status为 1（加工中），记录start_time。操作员点“完成”时再调一次，把状态改为 2，写end_time，同时更新product_sn_trace.current_op_seq为下一道工序序号。这个“两次报工”的设计能拿到真实加工时长，比只报一次完成要准得多。
3. 加工装配报工与返修闭环：从扫码到追溯的完整链路
3.1 扫码报工的三个状态跃迁与时间戳计算
加工装配现场最怕的是“事后补录”，所以 SimpleMES 的报工必须绑定扫码动作。一个工位上的标准流程是：扫工单条码 → 扫 SN → 系统校验 → 点开始 → 加工 → 点完成。对应到数据库，operation_instance的状态从 0 变 1 再变 2，start_time和end_time自动写入。这里有个细节：如果操作员扫了 SN 但没点开始就点了完成，系统应该拒绝，因为start_time为空。我一般会在后端加一个校验：op_status=0时只允许“开始”操作，op_status=1时只允许“完成”或“返修”操作。
时间戳计算加工时长时，注意end_time - start_time得到的是秒数，但车间可能有跨班次的情况。常见做法是只算自然时长，不扣休息，因为 MES 的定位是记录事实，不是算工资。如果确实要扣休息，那需要在operation_instance上加pause_time字段，操作员点“暂停”时累加。但多数中小厂不需要这么细，加了反而增加操作负担。
3.2 返修返修模块：汽车水冷板场景下的批次追溯怎么写
汽车水冷板的返修有个典型场景：气密测试不合格，拆下水冷板换新件，旧件要退回供应商分析。这时候 SimpleMES 的返修模块要做三件事：记录返修原因、记录换件批次、保持原工单追溯链不断。具体操作是在operation_instance上把op_status改为 3（返修中），然后插入一条rework_record，old_batch填拆下的水冷板批次，new_batch填新装上的批次。同时material_consumption里插两条记录：一条qty=-1对应旧批次，一条qty=+1对应新批次。
# 返修换件接口的核心逻辑（Python + SQLAlchemy 伪代码） def rework_replace(op_inst_id, old_batch, new_batch, reason, operator): op = session.query(OperationInstance).get(op_inst_id) if op.op_status != 2: raise ValueError("只有已完成的工序才能返修") # 1. 工序状态改为返修中 op.op_status = 3 # 2. 写返修记录 rework = ReworkRecord( op_inst_id=op_inst_id, rework_reason=reason, rework_action="更换水冷板", old_batch=old_batch, new_batch=new_batch, operator_id=operator ) session.add(rework) # 3. 物料消耗：旧件退料，新件消耗 session.add(MaterialConsumption( op_inst_id=op_inst_id, material_code="WL-8801", material_batch=old_batch, qty=-1 )) session.add(MaterialConsumption( op_inst_id=op_inst_id, material_code="WL-8801", material_batch=new_batch, qty=1 )) # 4. 返修完成后工序状态回到已完成 op.op_status = 2 session.commit()逻辑说明：这段代码的关键是“先校验再改状态”，防止对未完成的工序做返修。qty=-1和qty=+1成对出现，保证净消耗不变，但批次追溯能查到旧件去向和新件来源。rework_action字段写具体动作，方便后续按返修类型统计。
参数说明：old_batch和new_batch必须来自实际扫码，不能手输，否则追溯就是假的。operator从登录会话取，不要从前端传，防止伪造。返修记录不删除，只追加，这是追溯系统的底线。
3.3 用 WebService 对接老 ERP 的工单同步
很多工厂的 ERP 还是十几年前的，只支持 WebService（SOAP）。SimpleMES 加工装配系统要跟它对接，常见做法是写一个定时任务，每 5 分钟调一次 ERP 的getWorkOrderList方法，拿到新工单后转成内部 JSON 再调自己的下发接口。WebService 的 WSDL 地址一般由 ERP 厂商提供，字段映射要手工对一遍，尤其是日期格式和数量单位。
# 用 curl 测试 WebService 连通性（SOAP 1.1） curl -X POST http://erp-host/Service.asmx \ -H "Content-Type: text/xml; charset=utf-8" \ -H "SOAPAction: http://tempuri.org/getWorkOrderList" \ -d '<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getWorkOrderList xmlns="http://tempuri.org/"> <dateFrom>2025-01-01</dateFrom> <dateTo>2025-01-31</dateTo> </getWorkOrderList> </soap:Body> </soap:Envelope>'逻辑说明：SOAPAction头必须和 WSDL 里定义的一致，否则 ERP 会返回 500。日期格式看 ERP 要求，有的要yyyy-MM-dd，有的要yyyyMMdd。返回的 XML 用 Python 的xml.etree.ElementTree解析，注意命名空间。
参数说明：dateFrom和dateTo建议按天增量拉，不要一次拉一个月，防止超时。如果 ERP 支持分页，优先用分页。同步失败要有重试机制，但重试次数不要超过 3 次，避免把 ERP 打挂。
4. SimpleMES 加工装配系统避坑：五个让项目翻车的真实原因
4.1 坑一：工位扫码枪重复触发导致重复报工
现象：操作员扫一次 SN，系统里出现两条报工记录，done_qty多算了一个。原因：扫码枪的“回车后缀”配置成了连续发送，或者前端没做防抖。解决：前端在扫码输入框加 500ms 防抖，后端在报工接口用sn + op_seq做唯一约束，重复插入直接返回“已报工”。数据库层面加UNIQUE KEY uk_sn_op (sn, op_seq)最彻底。
4.2 坑二：返修后原工单完成数量被重复统计
现象：一台产品返修后重新报工，work_order.done_qty加了两次。原因：返修完成时又走了一遍正常报工逻辑。解决：返修完成只更新operation_instance.op_status回 2，不触发done_qty累加。done_qty只在首次从 1 变 2 时加一，用op_status的前后值判断。
4.3 坑三：物料批次号手输导致追溯断链
现象：追溯查询时发现某批水冷板查不到装到了哪些 SN 上。原因：操作员嫌扫码麻烦，手工输入批次号，输错了一位。解决：material_batch字段只允许扫码枪输入，前端设为readonly，后端校验批次号是否存在于物料批次主数据表。不存在就拒绝报工。
4.4 坑四：WebService 同步工单时字段映射错位
现象：ERP 下发的工单在 SimpleMES 里产品编码变成了数量。原因：WSDL 里字段顺序和实际返回不一致，解析时按位置取值了。解决：永远按标签名取值，不要按索引。解析后先打印一条日志，人工核对前三条数据再批量跑。
4.5 坑五：工控机浏览器缓存导致页面不刷新
现象：操作员报工后页面没变化，以为没成功，又扫了一次。原因：工控机浏览器缓存了旧版 JS。解决：静态资源加版本号查询串，比如app.js?v=20250101。或者用Cache-Control: no-cache响应头。车间工控机建议锁定浏览器版本，不要自动更新。
5. 把 SimpleMES 用出进阶价值：追溯报表与产线节拍分析
5.1 用一条 SQL 查出任意 SN 的完整加工装配履历
追溯报表不需要复杂的 BI 工具，一条 JOIN 查询就能把 SN 经过的工序、操作员、物料批次全拉出来。下面这条 SQL 在 MySQL 里跑，输入一个 SN 就能看到全貌。
SELECT t.sn, o.op_seq, o.op_name, o.station_code, o.operator_id, o.start_time, o.end_time, TIMESTAMPDIFF(SECOND, o.start_time, o.end_time) AS duration_sec, m.material_code, m.material_batch, m.qty, r.rework_reason, r.old_batch, r.new_batch FROM product_sn_trace t JOIN operation_instance o ON o.wo_id = t.wo_id LEFT JOIN material_consumption m ON m.op_inst_id = o.id LEFT JOIN rework_record r ON r.op_inst_id = o.id WHERE t.sn = 'SN20250101-0001' ORDER BY o.op_seq, m.scan_time;逻辑说明：LEFT JOIN保证没有物料消耗或返修记录的工序也能显示。TIMESTAMPDIFF算秒数，方便后续算平均节拍。ORDER BY o.op_seq保证按工序顺序排列。
参数说明：sn加引号，如果是变量传入注意防注入。如果数据量大，product_sn_trace.sn必须有索引，否则这条查询会全表扫。
5.2 产线节拍分析：从报工时间戳算出瓶颈工位
有了start_time和end_time，就能算每个工位的平均加工时长。按station_code分组，取AVG(duration_sec)，最高的那个就是瓶颈。我一般会建议每周跑一次，连续三周最高的工位就要考虑加人或者改工艺。注意要排除返修记录，因为返修时长不代表正常节拍。
SELECT station_code, COUNT(*) AS op_count, AVG(TIMESTAMPDIFF(SECOND, start_time, end_time)) AS avg_sec, MAX(TIMESTAMPDIFF(SECOND, start_time, end_time)) AS max_sec FROM operation_instance WHERE op_status = 2 AND start_time >= '2025-01-01' AND end_time < '2025-02-01' GROUP BY station_code ORDER BY avg_sec DESC;逻辑说明：op_status = 2只统计正常完成的工序，排除返修中。时间范围按需改。MAX用来发现异常长尾，如果某个工位max_sec特别大，可能是操作员忘了点完成。
参数说明：avg_sec是秒，除以 60 得分钟。如果产线有多个班次，可以再加operator_id分组看个人差异，但不要用来考核，否则数据会失真。
5.3 我踩过的坑和留给你的习惯
SimpleMES 这类轻量 MES 加工装配系统，最大的价值不是功能多，而是数据真。我见过太多项目死在“操作员不愿意扫码”上，最后追溯报表全是手工补录的假数据。我的习惯是：上线第一周，每天早会拿追溯报表点名表扬扫码最完整的工位，不批评落后的。第二周开始，把返修记录和批次追溯当成质量例会的固定议题。第三周，产线节拍分析自然就有人来问了。技术方案再漂亮，落不了地就是零。希望帮到你。
本文还有配套的精品资源，点击获取
