SimpleMES实战：加工装配车间工单流转与报工系统搭建

简介这是一套面向制造业信息化开发者与MES学习者的加工装配模拟系统源码与设计资料基于.NET 4.0构建适合希望理解车间级生产执行流程、研究服务端与客户端协同逻辑的中级开发者参考。资源包共445个文件约10MB以cs源码、dll程序集、resx与resources资源文件、txt说明、config配置及exe可执行文件为主另含png、jpg界面素材与wav提示音并附带mdf、ldf数据库文件及docx设计说明书。系统分为服务端与客户端两大部分服务端涵盖产品、物料、工序、工位、工艺路线等基础档案加工与装配计划管理实时看板数据初始化及标签初始化工具并提供实时监听服务客户端则实现加工与装配的过程控制、搬运控制以及质量异常处理核心业务逻辑通过数据库存储过程实现。开发环境为Visual Studio 2010搭配SQLServer2008R2DB文件夹内数据库文件附加即可运行Doc文件夹中提供《SimpleMES加工装配模拟系统》设计说明书。目前已有557人学习适合对照源码梳理MES业务链路与数据库设计思路。1. 从一张工单跑不通说起SimpleMES 到底解决加工装配车间的什么问题很多中小制造企业的车间里工单流转靠的是 Excel 加微信群。计划员排好生产任务打印一张纸质派工单送到产线操作工做完一道工序在单子上手写签名班组长下班前收回来录入电脑。这套流程在订单量小的时候勉强能转一旦遇到多品种、小批量、插单频繁的情况问题就集中爆发工单做到哪道工序了没人说得清返工返修记录散落在不同人的本子上装配缺件停线了才发现物料没到齐。SimpleMES 这类轻量级 MES 系统要解决的正是加工装配车间从派工到报工、从物料齐套到质量追溯的闭环管理问题。它不追求覆盖整个工厂的所有环节而是把「工单下发—工序流转—数据采集—异常反馈」这条主线跑通让车间主任打开电脑就能看到每张工单的实时状态。适合谁用适合那些年产值几千万到两亿之间、有加工和装配混合工序、IT 预算有限但迫切想把车间数据管起来的制造企业。下面从系统拆解、环境搭建、核心模块实现到避坑一步步讲清楚怎么把 SimpleMES 跑起来、用起来。2. SimpleMES 的模块拆解与加工装配场景映射2.1 加工装配车间的四个核心数据流在动手搭系统之前先把车间里实际发生的数据流理清楚。SimpleMES 的模块划分不是拍脑袋定的它对应的是加工装配场景中四条必须打通的链路。第一条是工单流。计划部门下达生产工单工单包含产品型号、数量、交期、工艺路线。工单流的核心状态机是已创建 → 已下达 → 生产中 → 已完工 → 已关闭。每个状态变更都要记录时间戳和操作人这是后续做产能分析和交期预警的基础。第二条是工序流。一张工单按工艺路线拆成多道工序每道工序有指定的工位、设备、标准工时。工序流要管的是当前工单走到哪道工序了、这道工序由谁在做、做了多少件合格品、多少件不良品。加工和装配的区别在于加工工序通常有设备参数需要采集装配工序更关注物料齐套和防错。第三条是物料流。装配工序开始前必须确认所需物料是否齐套。SimpleMES 里通常用「齐套检查」这个动作来卡住物料不齐工单不允许开工。物料流还要记录批次号这是后续做质量追溯的关键字段。第四条是质量流。加工装配过程中产生的检验记录、不良品处理、返工返修记录都要挂在对应的工单和工序上。汽车水冷板这类产品的返工返修模块尤其重要因为返修往往涉及多道工序的回退和重新报工状态机比正常生产复杂得多。这四条流在数据库里通过工单号关联形成一个以工单为中心的数据网络。理解了这一点再看 SimpleMES 的表结构就不会迷路。2.2 技术选型为什么用 Spring Boot Vue 而不是全栈低代码SimpleMES 这类系统的技术选型常见做法是后端 Spring Boot、前端 Vue、数据库 MySQL、缓存 Redis。为什么不用低代码平台快速搭因为 MES 的核心逻辑在工序状态流转和并发报工上低代码平台在处理「同一工单多工位同时报工」这种场景时事务控制和锁粒度往往不够精细后期性能出问题很难优化。后端用 Spring Boot 的好处是生态成熟MyBatis-Plus 做 CRUD、Spring Security 做权限、WebSocket 做车间看板实时刷新都有现成方案。前端用 Vue Element Plus产线平板和车间大屏都能适配。数据库 MySQL 8.0 起步工单表和报工记录表的数据量增长最快需要提前规划索引和分表策略。部署方式上小厂可以单机 Docker Compose 跑起来工单量大的话把 MySQL 和 Redis 独立部署。下面给出一个最小化的环境搭建步骤。2.3 本地跑通 SimpleMES 的最小命令集假设你已经装好了 Docker 和 Docker Compose按以下步骤操作。# 1. 创建项目目录 mkdir -p simplemes/{mysql,redis,app} cd simplemes # 2. 编写 docker-compose.yml cat docker-compose.yml EOF version: 3.8 services: mysql: image: mysql:8.0 container_name: mes-mysql environment: MYSQL_ROOT_PASSWORD: Mes2024 MYSQL_DATABASE: simplemes ports: - 3306:3306 volumes: - ./mysql/data:/var/lib/mysql - ./mysql/init:/docker-entrypoint-initdb.d command: --character-set-serverutf8mb4 --collation-serverutf8mb4_unicode_ci redis: image: redis:7-alpine container_name: mes-redis ports: - 6379:6379 volumes: - ./redis/data:/data app: build: ./app container_name: mes-app ports: - 8080:8080 depends_on: - mysql - redis environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/simplemes?useUnicodetruecharacterEncodingutf8 SPRING_DATASOURCE_USERNAME: root SPRING_DATASOURCE_PASSWORD: Mes2024 SPRING_REDIS_HOST: redis EOF # 3. 启动基础服务 docker compose up -d mysql redis # 4. 等待 MySQL 初始化完成后启动应用 docker compose up -d app这段 compose 文件定义了三个服务MySQL 负责持久化工单和报工数据Redis 缓存工位状态和会话信息app 是 Spring Boot 应用。关键参数说明MYSQL_ROOT_PASSWORD和SPRING_DATASOURCE_PASSWORD必须一致否则应用连不上数据库character-set-serverutf8mb4是为了支持中文工单备注和产品名称depends_on只保证启动顺序不保证 MySQL 已经初始化完毕所以实际部署时 app 服务需要加健康检查或重试逻辑。启动完成后访问http://localhost:8080应该能看到登录页。默认管理员账号通常在初始化 SQL 里预设常见做法是 admin / admin123首次登录后强制修改密码。2.4 工单表与报工表的结构设计要点SimpleMES 的数据模型里两张表的设计质量直接决定后期查询性能。-- 工单主表 CREATE TABLE work_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 工单号业务唯一键, product_code VARCHAR(64) NOT NULL COMMENT 产品编码, product_name VARCHAR(128) DEFAULT NULL, plan_qty INT NOT NULL DEFAULT 0 COMMENT 计划数量, completed_qty INT NOT NULL DEFAULT 0 COMMENT 已完工数量, status TINYINT NOT NULL DEFAULT 0 COMMENT 0已创建 1已下达 2生产中 3已完工 4已关闭, priority TINYINT DEFAULT 5 COMMENT 优先级数字越小越优先, plan_start_time DATETIME DEFAULT NULL, plan_end_time DATETIME DEFAULT NULL, actual_start_time DATETIME DEFAULT NULL, actual_end_time DATETIME DEFAULT NULL, create_by VARCHAR(64) DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_status_priority (status, priority), KEY idx_plan_end (plan_end_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT工单主表; -- 报工记录表 CREATE TABLE work_report ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, process_code VARCHAR(32) NOT NULL COMMENT 工序编码, station_code VARCHAR(32) DEFAULT NULL COMMENT 工位编码, operator VARCHAR(64) NOT NULL COMMENT 操作工, ok_qty INT NOT NULL DEFAULT 0 COMMENT 合格数量, ng_qty INT NOT NULL DEFAULT 0 COMMENT 不良数量, report_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, remark VARCHAR(255) DEFAULT NULL, PRIMARY KEY (id), KEY idx_order_process (order_no, process_code), KEY idx_report_time (report_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT报工记录表;工单表的order_no加了唯一索引防止重复下达。idx_status_priority这个联合索引是为了车间看板按状态和优先级筛选工单时走索引。报工表的idx_order_process支持按工单和工序快速汇总已报工数量idx_report_time用于按时间段统计产能。一个容易忽略的点completed_qty不要每次报工时用UPDATE work_order SET completed_qty completed_qty ?直接累加高并发下会出现更新丢失。常见做法是在报工记录表插入成功后用定时任务或消息队列异步汇总更新工单主表或者用UPDATE ... SET completed_qty (SELECT SUM(ok_qty) FROM work_report WHERE order_no ?)这种子查询方式保证一致性但要注意加锁范围。3. 从派工到报工加工装配核心流程的代码实现3.1 工单下达与工序派工的接口逻辑工单创建后处于「已创建」状态计划员确认无误后执行下达操作。下达时系统要做三件事校验工单下的工艺路线是否完整、按工序生成派工记录、把工单状态改为「已下达」。Transactional(rollbackFor Exception.class) public void releaseWorkOrder(String orderNo) { WorkOrder order workOrderMapper.selectByOrderNo(orderNo); if (order null) { throw new BizException(工单不存在); } if (order.getStatus() ! WorkOrderStatus.CREATED) { throw new BizException(只有已创建的工单才能下达); } // 校验工艺路线 ListProcessRoute routes processRouteMapper.selectByProductCode(order.getProductCode()); if (CollectionUtils.isEmpty(routes)) { throw new BizException(产品未配置工艺路线无法下达); } // 生成派工记录 for (ProcessRoute route : routes) { DispatchRecord record new DispatchRecord(); record.setOrderNo(orderNo); record.setProcessCode(route.getProcessCode()); record.setProcessName(route.getProcessName()); record.setStationCode(route.getStationCode()); record.setPlanQty(order.getPlanQty()); record.setStatus(DispatchStatus.WAITING); dispatchRecordMapper.insert(record); } // 更新工单状态 order.setStatus(WorkOrderStatus.RELEASED); order.setActualStartTime(new Date()); workOrderMapper.updateById(order); }这段代码的关键在于事务边界。工单状态更新和派工记录生成必须在同一个事务里否则可能出现工单已下达但派工记录没生成的脏数据。Transactional(rollbackFor Exception.class)确保任何异常都回滚。参数说明orderNo是业务唯一键不是主键 ID这样接口对外更稳定。ProcessRoute里包含工序顺序号seqNo派工记录按这个字段排序操作工在平板上看到的工序列表就是按加工顺序排列的。3.2 报工接口的并发控制与数量校验报工是车间里调用最频繁的接口。一个工位可能同时有多张工单在流转操作工扫码报工时系统要快速响应并保证数量准确。PostMapping(/report) public Result? report(RequestBody Valid WorkReportDTO dto) { // 分布式锁防止同一工单同一工序并发报工 String lockKey mes:report: dto.getOrderNo() : dto.getProcessCode(); RLock lock redissonClient.getLock(lockKey); try { if (!lock.tryLock(3, 10, TimeUnit.SECONDS)) { return Result.fail(操作过于频繁请稍后重试); } // 校验累计报工数量不超过计划数量 int reportedQty workReportMapper.sumOkQty(dto.getOrderNo(), dto.getProcessCode()); DispatchRecord dispatch dispatchRecordMapper.selectByOrderAndProcess( dto.getOrderNo(), dto.getProcessCode()); if (reportedQty dto.getOkQty() dispatch.getPlanQty()) { return Result.fail(报工数量超出计划数量); } // 插入报工记录 WorkReport report new WorkReport(); BeanUtils.copyProperties(dto, report); report.setReportTime(new Date()); workReportMapper.insert(report); // 更新派工记录状态 if (reportedQty dto.getOkQty() dispatch.getPlanQty()) { dispatch.setStatus(DispatchStatus.FINISHED); dispatchRecordMapper.updateById(dispatch); } return Result.ok(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return Result.fail(系统繁忙); } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } } }这里用 Redisson 的分布式锁而不是 Java 自带的synchronized因为应用可能多实例部署。锁的粒度是「工单号 工序编码」不同工单之间不互相阻塞。tryLock(3, 10, TimeUnit.SECONDS)表示最多等 3 秒获取锁持有锁超过 10 秒自动释放防止死锁。数量校验的逻辑是已报工数量加上本次报工数量不能超过派工数量。这个校验必须在锁内执行否则两个请求同时读到相同的已报工数量都会通过校验导致超报。这是血泪经验早期版本没加锁产线工人连续点两次报工按钮就出现了超报。3.3 装配齐套检查的实现方式装配工序和加工工序最大的区别在于物料齐套。加工工序通常只关心设备和刀具装配工序开工前必须确认所有物料都到位了。public CheckResult checkKitting(String orderNo, String processCode) { // 查询该工序的 BOM 用料 ListBomItem bomItems bomItemMapper.selectByProductAndProcess( workOrderMapper.selectByOrderNo(orderNo).getProductCode(), processCode); ListString shortageList new ArrayList(); for (BomItem item : bomItems) { // 查询线边仓库存 int stockQty inventoryMapper.selectStockQty(item.getMaterialCode()); if (stockQty item.getQtyPerUnit() * planQty) { shortageList.add(item.getMaterialCode() 缺 (item.getQtyPerUnit() * planQty - stockQty) 件); } } CheckResult result new CheckResult(); if (shortageList.isEmpty()) { result.setPass(true); result.setMessage(齐套检查通过); } else { result.setPass(false); result.setMessage(缺料 String.join(, shortageList)); } return result; }齐套检查的触发时机有两个一是工单下达时做预检查提前暴露缺料风险二是装配工序开工前做正式检查不通过则不允许报工。qtyPerUnit是单台用量乘以计划数量得到总需求。线边仓库存要实时扣减领料出库时就要更新不能等到报工时才扣。一个实际踩过的坑BOM 里有些物料是共用料多个工单同时抢料。齐套检查时如果只查总库存会出现两个工单都显示齐套、实际领料时不够的情况。解决办法是按工单做物料预留或者齐套检查时把已预留数量扣除。3.4 返工返修流程的状态机设计汽车水冷板这类产品的返工返修模块是 SimpleMES 里状态机最复杂的部分。正常生产是单向流返修可能涉及工序回退、部分数量返修、返修后重新检验。返修单的核心字段包括原工单号、返修工序、返修数量、返修原因、返修后状态。状态流转是待返修 → 返修中 → 待检验 → 返修完成 / 返修报废。public void createReworkOrder(ReworkCreateDTO dto) { // 校验原工单存在且已完工或生产中 WorkOrder origin workOrderMapper.selectByOrderNo(dto.getOriginOrderNo()); if (origin null) { throw new BizException(原工单不存在); } // 校验返修数量不超过原工单不良数量 int totalNgQty workReportMapper.sumNgQty(dto.getOriginOrderNo()); int alreadyReworkQty reworkOrderMapper.sumQtyByOrigin(dto.getOriginOrderNo()); if (alreadyReworkQty dto.getReworkQty() totalNgQty) { throw new BizException(返修数量超过不良数量); } ReworkOrder rework new ReworkOrder(); rework.setReworkNo(generateReworkNo()); rework.setOriginOrderNo(dto.getOriginOrderNo()); rework.setProcessCode(dto.getProcessCode()); rework.setReworkQty(dto.getReworkQty()); rework.setReason(dto.getReason()); rework.setStatus(ReworkStatus.WAITING); reworkOrderMapper.insert(rework); // 原工单状态回退到生产中 origin.setStatus(WorkOrderStatus.IN_PRODUCTION); workOrderMapper.updateById(origin); }返修单和原工单通过originOrderNo关联返修完成后要更新原工单的合格数量。这里有个容易翻车的地方返修可能只针对部分不良品比如不良 10 件先返修 5 件剩下 5 件等物料到了再返修。所以返修数量要累计校验不能单次校验。alreadyReworkQty就是已创建返修单的数量总和。4. 部署与运行中容易翻车的五个坑4.1 坑一MySQL 连接池耗尽导致报工接口超时现象产线高峰期多个工位同时报工接口响应时间从 200ms 飙升到 5 秒以上部分请求直接超时。原因Spring Boot 默认 HikariCP 连接池最大连接数是 10报工接口里嵌套了多个查询和更新每个请求占用连接时间较长并发一上来连接池就不够用了。解决把spring.datasource.hikari.maximum-pool-size调到 30 到 50同时优化报工接口里的 SQL把能合并的查询合并。另外检查是否有慢 SQL 占着连接不放开spring.datasource.hikari.leak-detection-threshold5000可以打印连接泄漏日志。4.2 坑二工单号生成规则冲突现象偶尔出现工单号重复插入时报唯一键冲突。原因工单号用「日期 流水号」生成流水号从 Redis 自增获取。Redis 重启后自增 key 丢失流水号从 1 重新开始和当天已生成的工单号撞车。解决Redis 自增 key 要设置过期时间到当天结束并且应用启动时从数据库查当天最大流水号回填 Redis。更稳妥的做法是用数据库序列表或者雪花算法生成工单号。我一般会选数据库序列表简单可靠。4.3 坑三车间平板浏览器缓存导致页面不刷新现象操作工报工后看板上的数量没有实时更新刷新页面才变。原因车间平板用的是旧版浏览器WebSocket 连接不稳定断线后没有自动重连。另外前端静态资源缓存策略太激进新版本发布后平板还在用旧代码。解决WebSocket 加心跳检测和自动重连断线后每 5 秒重试。前端静态资源文件名加 hashHTML 设置Cache-Control: no-cache。平板端建议用 PWA 或者封装成安卓应用减少浏览器兼容性问题。4.4 坑四齐套检查通过但领料时发现缺料现象系统显示齐套装配工去领料仓库说库存不够。原因齐套检查查的是线边仓库存但线边仓和仓库实际库存没有实时同步。领料出库单还没过账系统里线边仓库存已经加上了。解决齐套检查的数据源要统一。要么查仓库实时库存要么线边仓库存必须由领料出库单审核后触发更新不能提前加。另外做物料预留齐套检查通过后立即预留对应数量防止其他工单抢料。4.5 坑五返修工单完工后原工单状态没更新现象返修单已经完成检验但原工单的合格数量没有增加看板显示还是不良状态。原因返修完工的逻辑里只更新了返修单状态忘了回写原工单。或者回写时用的工单号是返修单号而不是原工单号。解决返修完工接口里显式调用原工单更新逻辑用originOrderNo查询原工单。建议在返修单表里冗余原工单的产品编码和数量信息减少关联查询。测试时要覆盖「部分返修」「多次返修」「返修报废」三种场景。5. 用看板数据反查工序瓶颈一个我常用的分析技巧SimpleMES 跑起来之后最有价值的不是报工本身而是积累下来的工序时间数据。我习惯用报工记录表里的report_time和派工记录里的plan_start_time做差算出每道工序的实际加工时长再按工位汇总找出瓶颈工序。具体做法是写一个定时任务每天凌晨跑一次把前一天的数据汇总到工序产能分析表里。INSERT INTO process_capacity_analysis (stat_date, process_code, station_code, avg_duration_min, total_ok_qty, total_ng_qty) SELECT DATE(wr.report_time) AS stat_date, wr.process_code, wr.station_code, AVG(TIMESTAMPDIFF(MINUTE, dr.actual_start_time, wr.report_time)) AS avg_duration_min, SUM(wr.ok_qty) AS total_ok_qty, SUM(wr.ng_qty) AS total_ng_qty FROM work_report wr JOIN dispatch_record dr ON wr.order_no dr.order_no AND wr.process_code dr.process_code WHERE wr.report_time DATE_SUB(CURDATE(), INTERVAL 1 DAY) AND wr.report_time CURDATE() GROUP BY DATE(wr.report_time), wr.process_code, wr.station_code;这个查询按工序和工位统计平均加工时长、合格数和不良数。TIMESTAMPDIFF(MINUTE, ...)算出从派工开始到报工结束的分钟数。注意这里用的是派工记录的actual_start_time如果这个字段为空说明操作工没有点「开工」直接报工了统计时要把这类记录排除。拿到这张分析表后按avg_duration_min降序排列排在前面的就是瓶颈工序。如果某个工位的平均加工时长明显高于同工序其他工位可能是设备老化或者操作工不熟练。如果某个工序的不良数突然升高往前查对应时间段的报工记录看是哪个操作工、哪批物料。我一般会把这个分析结果做成车间大屏上的一个页面每天更新。班组长看到自己工位的平均时长超标了会主动去查原因。这比开会强调效率管用得多。还有一个进阶用法把工序实际时长和标准工时对比算出偏差率。偏差率超过 30% 的工单标红计划员排产时就能避开这些异常工位。这个功能不需要多复杂的算法一个 SQL 加一个前端表格就能实现但实际用起来对交期达成率的提升很明显。最后说一个我自己的习惯每次系统上线新功能先在一个工位上试跑一周只让一个操作工用记录他遇到的每一个问题。等这个工位跑顺了再推广到全线。MES 系统的坑大多不在代码里在操作工的使用习惯里。希望帮到你。本文还有配套的精品资源点击获取