简介一套基于.NET 4.0的SimpleMES加工装配模拟系统面向MES系统学习者、课程设计或毕业设计人员以及需要快速搭建制造执行原型的开发者。服务端与客户端分工明确服务端包含基础档案、加工与装配计划管理、实时看板和数据初始化客户端覆盖加工、装配及搬运过程控制和质量异常处理核心业务逻辑封装于数据库存储过程便于深入研究MES的调度与数据流转。资源包共445个文件压缩后约10MB以175个C#源码、36个DLL库和12个EXE程序为主体并附带MDF/LDF/BAK数据库文件、DOCX设计说明书、配置文件、图片及WAV提示音频其中DB目录可直接附加数据库Doc目录包含完整设计说明。已有557人学习下载借助这套资源不仅能获得可运行的服务端与客户端工程还可结合说明书理解计划、看板、实时监听与异常处理之间的联动适合作为Visual Studio 2010与SQL Server 2008 R2环境下的二次开发蓝本。1. 装配车间上MES最容易翻车的地方为什么SimpleMES能绕过去机械加工装配类的中小车间选MES普遍卡在一个尴尬位置大厂MES实施周期长、顾问费比软件费贵一线班组根本不买账纯靠Excel加微信群报数又永远对不上在制数和齐套率。SimpleMES这类轻量级方案恰好把加工装配场景里最核心的东西收成一张可维护的工单流工艺路线、多级BOM、工序报工、齐套检查和异常处理而且它常见的技术底座是若依框架扩展方式清楚不依赖原厂顾问。这套逻辑更适合预算有限、想先用起来再迭代的数字化专员、车间主任和负责落地的IT工程师。很多人把MES想成一个大黑匣子其实加工装配类MES的骨架一张工单流转表就能说清楚。2. SimpleMES的数据建模核心物料、多级BOM和工艺路线怎么落到一张工单上2.1 基于若依框架的MESSimpleMES把哪些能力白送给了你若依框架在Java技术栈里普及度很高基于若依框架的MES项目一搜一大把SimpleMES是其中偏向加工装配场景的一种开源实现。选这个底座的直接好处是用户管理、角色权限、菜单管理、操作日志、定时任务、代码生成器这些通用模块齐全不用从零写。你做MES时最费时间的是业务建模而不是用户登录和按钮权限这些重复工作。RuoYi-Vue的技术栈是Spring Boot加Vue加MyBatis加MySQL招人容易二次开发门槛低。很多车间没有专职架构师找一个能写SSM的工程师就能维护这是我推荐它在中小厂落地的主要原因之一。再加上若依自带定时任务和缓存监控MES里最常用的工单超时预警、设备状态心跳检测都能直接挂在框架的调度器上不需要额外引一套任务系统。2.2 物料主数据先理清三件事编码、单位、批次加工装配车间的物料特点是层级多半成品要过好几道工序才变成成品。物料主数据如果建不好后边的BOM展开、齐套计算、报工入库全是错的。我一般建议在建SimpleMES的基础数据时先把这三件事定死。第一物料编码全局唯一禁用中文名当主键。第二物料类型的边界要清楚原材料、半成品、成品三类区分开装配场景中半成品是否要建独立物料编码要在项目启动会上拍板。第三批次管理默认开启哪怕现在的库存量不大也要开。理由是装配场景的追溯诉求很强一旦客户投诉或者来料不良你要能从成品条码倒查到批次、供应商和加工记录没有批次字段这个追溯链就断了。物料主数据在SimpleMES里通常对应的建表逻辑如下CREATE TABLE mes_material ( material_id BIGINT AUTO_INCREMENT PRIMARY KEY, material_code VARCHAR(64) NOT NULL UNIQUE COMMENT 物料编码全局唯一, material_name VARCHAR(128) NOT NULL COMMENT 物料名称, material_type CHAR(1) NOT NULL COMMENT 类型1原材料 2半成品 3成品, unit VARCHAR(8) NOT NULL DEFAULT PCS COMMENT 基本单位, is_batch TINYINT NOT NULL DEFAULT 1 COMMENT 批次管理1开启 0关闭, safety_stock DECIMAL(12,2) DEFAULT 0 COMMENT 安全库存, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB COMMENT物料主数据;这里的关键参数是material_type和is_batch。类型会影响后续BOM展开时是否要继续往下拆批次管理建议生产型和贸易型的物料都开别为了省事关掉。单位这里建议统一到最小计量单位装配车间经常混用“套”和“件”如果不统一报工数量换算会踩坑。导入物料时常见的做法是先把Excel模板导出清洗后通过若依代码生成器做成的导入功能批量入表。要注意Excel里如果编码重复MySQL的唯一索引会直接抛错数据库层面加一道保险比什么都管用。2.3 装配场景的关键配置多级BOM展开与工艺路线绑定装配BOM的难点不是建父子关系而是变更多。今天换了一个供应商螺栓规格变了整条装配路径的物料需求都要跟着变。SimpleMES里通常把BOM和工艺路线分开维护工单创建时选择“BOM版本加工艺路线版本”的组合再取组合后的快照数据。这样老工单继续走老BOM新工单自动用新版本不会互相污染。多级BOM展开的SQL在MySQL里可以靠递归CTE完成。加工装配的叶子节点可能是采购件也可能自加工件但齐套计算只关心最底层物料需求所以要递归展开到叶子。我给一个可以直接调试的版本-- 按BOM版本递归展开到叶子物料并折算成根节点的用量系数 WITH RECURSIVE bom_flat AS ( SELECT material_id, parent_id, qty, 1 AS level FROM mes_bom_item WHERE bom_revision_id 1001 AND parent_id 0 UNION ALL SELECT c.material_id, c.parent_id, c.qty * p.qty, p.level 1 FROM bom_flat p JOIN mes_bom_item c ON c.parent_id p.material_id WHERE c.bom_revision_id 1001 ) SELECT material_id, SUM(qty) AS unit_qty FROM bom_flat GROUP BY material_id;这段SQL的逻辑是先取根节点然后逐层往下子项的用量乘以父项的累计系数。bom_revision_id是BOM版本的外键parent_id 0表示根节点。展开后得到的unit_qty是单位成品的物料需求量后面跟工单数量相乘就得到总需求。注意递归CTE在MySQL 8.0以上才支持如果是5.7要么换写法或者升级数据库这一点会在老车间部署时经常发生提前确认版本能省不少麻烦。工艺路线相对简单一张表就能维护CREATE TABLE mes_route_process ( id BIGINT AUTO_INCREMENT PRIMARY KEY, route_id BIGINT NOT NULL COMMENT 工艺路线ID, process_seq INT NOT NULL COMMENT 工序顺序从10开始, process_name VARCHAR(64) NOT NULL COMMENT 工序名称如装配、点焊、老化, workcenter_id BIGINT NOT NULL COMMENT 工作中心ID关联产线或工位, standard_hours DECIMAL(8,2) COMMENT 标准工时小时, is_check TINYINT DEFAULT 0 COMMENT 是否必检工序1是 0否 ) ENGINEInnoDB COMMENT工艺路线工序表;process_seq我建议按10、20、30递增编号中间要插工序时不用重排。有了这张表工单创建时按process_seq排序批量生成工序实例后续报工就是逐个工序走状态逻辑就清晰了。很多MES说明书里把“工单生成的同时复制工艺路线”叫工序实例化这是SimpleMES从建模走向执行最关键的一步。3. 从工单下达到完工入库SimpleMES的工序流转与报工逻辑3.1 一张工单在SimpleMES里怎么走完五步工序流转是加工装配MES的执行主线操作工所有的操作都围绕“当前工单当前工序”展开。常见流程分五步创建工单、下达车间、工序开工、报工、完工入库。创建工单的时候系统根据产品和数量的组合自动带出BOM版本、工艺路线版本并生成一批工序实例每道工序初始状态是等待开工。下达车间后班组长才能看到任务并派工到产线。每道工序等待开工不等于设备正在生产真正的开工动作是操作工扫码确认“我开始干了”这个时间点就是工时采集的起点。报工后系统校验合格数、不良数同时判断是否还有下一道工序全部工序完成后工单自动进入入库候选状态。这套流程的价值在于你不用额外安装设备采集硬件也能先把工序级数据采集起来。对装配车间来说设备自动化程度参差不齐人员动作数据比设备数据更重要。3.2 工单条码规则怎么定从4321这个编号说起标题里的4321我理解是一套工单编号规则的典型示例。实际编码结构可以拆成“4位产品系列 3位工艺版本 2位产线代码 1位班次代码”合起来就是一个可读、可追溯的工单号。关键不是数字位数而是扫码后系统能解析出产品、版本、产线和班次信息。生成工单号的Java代码也可以写得很直接public String buildWorkOrderCode(Product product, ProcessRoute route, String lineCode, Integer shiftCode) { // 4321规则示例产品系列4位 工艺版本3位 产线2位 班次1位 String productCode StringUtils.leftPad(product.getSeriesCode(), 4, 0); String routeCode StringUtils.leftPad(String.valueOf(route.getVersion()), 3, 0); String linePart StringUtils.leftPad(lineCode, 2, 0); String shiftPart String.valueOf(shiftCode); return productCode routeCode linePart shiftPart; }参数说明seriesCode是产品系列编码不是完整物料编码控制在4位只做标识不做含义解析。route.getVersion()是工艺路线版本号3位足够用到999个版本。lineCode建议直接用厂区编号不要用产线中文名避免条形码里出现中文导致扫码枪乱码。班次代码用1、2、3对应早中晚班。这里有一个很容易忽略的坑编码里不要加上日期日期变体天然每天不同会导致返工追溯困难。日期单独在数据库字段里保存扫码查询时传参即可不要把动态日期拼进条码。车间师傅扫了条码也看不出日期反而容易扫错工单。3.3 齐套检查装配车间最刚需的一张缺料清单装配场景的典型痛点是开工前发现缺料生产已经停了才发现仓库少一个贴片电容。齐套检查必须在工单下达前跑一次逻辑也很直白根据工单数量和BOM展开结果算需求减去可用库存大于零的就是缺料。-- 齐套检查需求数量减去可用库存返回缺料清单 WITH RECURSIVE bom_flat AS ( SELECT material_id, qty, 1 AS level FROM mes_bom_item WHERE bom_revision_id #{revisionId} AND parent_id 0 UNION ALL SELECT c.material_id, c.qty * p.qty, p.level 1 FROM bom_flat p JOIN mes_bom_item c ON c.parent_id p.material_id WHERE c.bom_revision_id #{revisionId} ) SELECT f.material_id, f.qty * #{orderQty} AS demand_qty, IFNULL(s.available_qty, 0) AS available_qty, f.qty * #{orderQty} - IFNULL(s.available_qty, 0) AS shortage_qty FROM (SELECT material_id, SUM(qty) AS qty FROM bom_flat GROUP BY material_id) f LEFT JOIN mes_material_stock s ON s.material_id f.material_id HAVING shortage_qty 0;这个查询的核心在available_qty字段。你库存表里的账面库存和可用库存一定不要混用。账面库存包括已经预留给其他工单的量如果直接拿账面数去算齐套就会得出虚假的“已齐套”真正开工时又缺料。我一般在mes_material_stock表里加一个reserved_qty字段可用库存等于库存总量减去预留量齐套检查只认可用库存。这是很多MES实施中后期才补的补丁建议一开始就按这个逻辑建表。3.4 报工事务为什么不能只写一条报工记录工序报工看着简单但它是MES里最容易出数据事故的地方。常见错误是只往报工表插入一条记录然后不管在制数量。正确的做法是报工插入和工序数量更新必须在同一个数据库事务里否则报工成功但工序状态没变在制数量就变成一笔糊涂账。/** * 工序报工写报工记录并更新工序完成数量 */ Transactional(rollbackFor Exception.class) public void reportProcess(ReportDTO dto) { WorkOrderProcess wp workOrderProcessMapper.selectByIdForUpdate(dto.getProcessId()); // 状态校验只有运行中的工序才允许报工 if (!RUNNING.equals(wp.getStatus())) { throw new BizException(工序状态不是运行中不能报工); } // 防错累计合格数量不能超过工单计划数量 BigDecimal finishedQty reportMapper.sumQualifiedQty(wp.getId()); if (finishedQty.add(dto.getQualifiedQty()).compareTo(wp.getPlanQty()) 0) { throw new BizException(报工数量超出工单剩余数量); } // 写入报工记录同时更新工序完成数量 reportMapper.insert(dto); wp.setFinishedQty(finishedQty.add(dto.getQualifiedQty())); // 全部完成则工序状态流转为已完成 if (wp.getFinishedQty().compareTo(wp.getPlanQty()) 0) { wp.setStatus(FINISHED); } workOrderProcessMapper.updateById(wp); }这段代码有三个关键细节。第一selectByIdForUpdate加行锁防止两个操作工同时扫同一道工序重复报工。第二报工数量与工序余量做校验这一步是“防错”装配车间常见的错装漏装问题通过数量校验能挡住一部分。第三Transactional保证报工记录和工序数量一起成功、一起失败不会出现报工了但数量没涨的情况。3.5 完工入库与后道工序解锁一个工单的最后一道工序报工完成后系统要自动把产品状态改成待入库同时对下道工序解除锁定。这是通过报工后的事件触发实现的而不是让操作工手动去点击“完工确认”。我见过很多项目在每一个环节都让人去点按钮操作工嫌烦最后直接不点数据就是死的。常见的实现方式是报工事务成功提交后通过Spring的事件发布机制监听工序完成事件然后自动判断process_seq是否为该工单最大的工序如果是就更新工单状态为完工。你要在报表上查“今日完工量”直接查这张工单状态即可不要在Excel里再汇总一遍。4. 基于若依框架的权限配置车间里谁该看什么一个按钮都不能多4.1 三套常用角色菜单操作工、班组长、计划员MES上线后最让车间反感的不是系统慢而是屏幕上堆满了和自己无关的菜单。SimpleMES基于若依框架的权限体系可以很好地按角色裁剪菜单。我一般建议分三套默认角色模板。操作工只保留“我的任务、工序报工、不良上报”班组长增加“工单查询、齐套检查、异常处理、人员派工”计划员增加“BOM维护、工艺路线维护、工单创建、库存查询、报表中心”。车间主任和管理层可能还要看“效率看板”但这类角色建议后置等数据稳定了再开。在若依框架里菜单权限通过perm字符串控制角色配菜单用SQL就能批量完成-- 给班组长角色批量绑定菜单权限 INSERT INTO sys_role_menu(role_id, menu_id) SELECT r.role_id, m.menu_id FROM sys_role r, sys_menu m WHERE r.role_key workshop_leader AND m.perms IN ( mes:workorder:list, mes:material:available, mes:exception:handle, mes:report:list );这段SQL用了SELECT ... FROM sys_role, sys_menu的笛卡尔积加条件过滤方式避免逐条手写INSERT。真正执行时可以把role_key换成你系统里实际的角色标识。菜单权限的粒度建议控制到按钮级操作工界面上连“删除工单”的按钮都不要出现因为越权的操作人员点错一次整条工单数据就乱了。4.2 数据权限让班组长只看到自己那条产线菜单权限控制能不能进某个页面数据权限控制进了页面能看哪些行。SimpleMES里常见的诉求是A线的班组长看不到B线的工单和报工记录。若依框架自带DataScope注解可以在查询前自动拼接数据过滤条件。/** * 工单查询列表数据权限自动过滤产线 */ DataScope(deptAlias d, userAlias u) public ListWorkOrder listWorkOrder(WorkOrderQuery query) { return workOrderMapper.selectWorkOrderList(query); }对应的Mapper XML里要预留数据权限拼接位置select idselectWorkOrderList parameterTypeWorkOrderQuery resultTypeWorkOrder SELECT w.order_id, w.order_code, w.product_id, w.plan_qty, w.status FROM mes_work_order w LEFT JOIN sys_dept d ON d.dept_id w.dept_id where if teststatus ! null AND w.status #{status} /if ${params.dataScope} /where /select${params.dataScope}是若依框架数据权限解释器自动拼接的SQL片段。关键是工单表上要挂dept_id这个部门对应实际产线不能随便挂一个行政部门的ID。如果工单表里没设计dept_id字段数据权限就无从谈起这是建模阶段就要预留的字段而不是上线后补。数据权限是MES项目里争议很大的功能建议上线第一天就开启后期再开会让工人觉得系统在“突然限制自己”反而不配合。4.3 字典参数与基础配置合格率阈值、工时版本、不良代码若依框架的字典管理可以直接复用。MES里最典型的字典是“工序状态”和“不良原因”。工序状态我建议就用四个等待开工、运行中、已完成、已关闭。太多状态会让操作工不知道选哪个太少又无法表达返工等场景。不良原因代码要提前跟质检部门对齐装配场景常见的有错装、漏装、外观划伤、扭矩超差、尺寸超差这五类宁可先少后补也不要让人在文本框里随手敲中文。合格的MES说明书应该把每个字段的解释、可选值和流转规则写清楚这比写代码重要得多。字典配置步骤很简单在若依管理后台的“字典管理”里新建字典类型mes_wo_status然后添加字典数据。这些数据在工单下拉框、报表筛选项里会自动生效不需要改前端代码。5. 加工装配场景里最常踩的5个坑按现象、原因、解决方案排查5.1 报工了但WIP在制数量对不上现象上午报工了120件下午查在制数量还是0或者变成了负数。整个车间在制数没人敢信。原因报工表和工序状态更新不在同一个事务里半路失败导致报工记录写进去了但工序数量没更新更常见的是直接在工单表存了一个冗余的wip_qty字段报工加一笔、入库减一笔中间任何一步漏了就对不上。解决不要单独存WIP字段在制数量永远通过“累计报工数量减去累计入库数量”实时算出来。报工、质检判定、入库、状态更新全部放进一个事务。每周让班组长抽查三个工单的在制数和现场实物进行比对坚持两周数据可信度就上来了。5.2 齐套检查显示齐套开工还是缺料现象工单下达前齐套检查通过了真正开工时仓库发不出料。原因齐套计算用了账面库存而不是可用库存。账面库存没有扣掉已经预留给其他工单的数量甚至没有扣掉已经被品质冻结的来料不良库存。解决库存表增加reserved_qty和frozen_qty两个字段。可用库存总库存-预留-冻结。同时把齐套检查从“即时查询”改成“工单下达时生成快照”缺少的物料锁定需求后续采购到货后自动释放预留。操作上仓库每次做库存异动时都要在系统里同步更新预留量这一步做不到齐套检查永远不准。5.3 扫码枪输入项目标题时自动跳过字符现象操作工扫工单条码输入框里偶尔少一个字符或者最后多一个回车符导致查询不到工单。原因扫码枪在键盘仿真模式下中文输入法会截断字符另外扫码枪默认的结束符是回车键看系统有没有自动把回车转成查询触发。输入框没有去空格和回车处理也是常见原因。解决扫码枪配置里把工作模式设置为“键盘仿真回车后缀”成本低兼容性好。代码层面对条码做统一处理接收到输入框的值先trim()掉首尾空白再去掉结尾的\r\n。查询按钮用回车事件触发这样扫码和手动回车都能得到一致结果。不要改用USB串口模式Windows和Linux的驱动配置差异会让你多踩三天坑。5.4 修改BOM后已下发的工单还在用旧版本但物料需求变了现象技术员改了装配BOM结果工单报工时物料需求全是错的要么多算要么少算。原因工单没有对BOM做版本快照BOM修改直接影响了在制工单。解决BOM表只做新增版本不做原地修改。每个工单创建时把BOM明细复制到工单BOM快照表后续查询物料需求都走快照表而不是JOIN最新BOM版本。这样做还有一个好处就是追溯历史工单时可以还原当时的BOM到底是什么样。这条准则同样适用于工艺路线工单一旦创建工艺版本不可变更除非显式做工序变更单。5.5 若依定时任务和MES轮询任务并发导致工序超时误报现象凌晨1点一批工单被自动标记为“超时”但是实际上班次是下午4点才结束。原因若依框架自带的定时任务默认每分钟扫描一次而MES工序超时检测任务也是独立调度的两个任务并发执行时超时检测读到了还没落库的班次结束事件。解决为超时检测任务补充“班次结束时间校验”逻辑只处理当前时间大于计划结束时间加缓冲时间的工单。在若依的调度管理里把两个任务的执行错开不要都放在整点。更重要的是给定时任务加上分布式锁避免多实例部署时重复触发。经验是MES里的定时任务一定要允许手动补跑否则一旦漏跑超时状态的数据补起来会非常费劲。6. 把SimpleMES从“记录系统”变成车间看板先盯住一条小时产出SQL很多MES项目死在上线三个月后没人看报表。要避免这个结局我的建议是不要一开始就做大而全的看板而是先盯住一条小时产出SQL。对车间主任来说今天现在这一刻产线干出了多少合格件比任何漂亮图表都管用。-- 按小时统计各工序的合格产出和折算标准工时 SELECT DATE_FORMAT(r.report_time, %Y-%m-%d %H:00) AS hour_bucket, wp.process_name, SUM(r.qualified_qty) AS qualified_qty, ROUND(SUM(r.qualified_qty * wp.standard_hours), 2) AS standard_hours FROM mes_report_record r JOIN mes_workorder_process wp ON r.process_id wp.id WHERE r.report_time NOW() - INTERVAL 24 HOUR GROUP BY hour_bucket, wp.process_name ORDER BY hour_bucket DESC, wp.process_name;要把这个查询跑起来前提是报工记录里带准确的时间戳并且每道工序实例上有standard_hours。很多实施项目把标准工时放在工艺路线表里工单工序实例没有复制一份结果报表只能按数量统计算不了效率。工序实例落库时把标准工时快照下来是我反复强调的一个点。报表稳定后可以算极简版OEE。口径不需要追求和教科书一致能用就行合格产出数量乘以标准工时除以设备可动工时。可动工时按班次时长减去计划停机时间。这样算出来的OEE有一个偏差但趋势是可靠的。对比每天的OEE波动再结合不良代码占比就能定位是哪个工序掉链子。等我回头看这些年做过的MES项目凡是能坚持三周核对小时产出数据的车间最后都把SimpleMES用成了真正管理的抓手凡是只看月报的都半途而废了。数据这种事你不能等它自己变准要拉着班组一起较真较真两三个礼拜大家才认账。希望帮到你。本文还有配套的精品资源点击获取
简介一套基于.NET 4.0的SimpleMES加工装配模拟系统面向MES系统学习者、课程设计或毕业设计人员以及需要快速搭建制造执行原型的开发者。服务端与客户端分工明确服务端包含基础档案、加工与装配计划管理、实时看板和数据初始化客户端覆盖加工、装配及搬运过程控制和质量异常处理核心业务逻辑封装于数据库存储过程便于深入研究MES的调度与数据流转。资源包共445个文件压缩后约10MB以175个C#源码、36个DLL库和12个EXE程序为主体并附带MDF/LDF/BAK数据库文件、DOCX设计说明书、配置文件、图片及WAV提示音频其中DB目录可直接附加数据库Doc目录包含完整设计说明。已有557人学习下载借助这套资源不仅能获得可运行的服务端与客户端工程还可结合说明书理解计划、看板、实时监听与异常处理之间的联动适合作为Visual Studio 2010与SQL Server 2008 R2环境下的二次开发蓝本。1. 装配车间上MES最容易翻车的地方为什么SimpleMES能绕过去机械加工装配类的中小车间选MES普遍卡在一个尴尬位置大厂MES实施周期长、顾问费比软件费贵一线班组根本不买账纯靠Excel加微信群报数又永远对不上在制数和齐套率。SimpleMES这类轻量级方案恰好把加工装配场景里最核心的东西收成一张可维护的工单流工艺路线、多级BOM、工序报工、齐套检查和异常处理而且它常见的技术底座是若依框架扩展方式清楚不依赖原厂顾问。这套逻辑更适合预算有限、想先用起来再迭代的数字化专员、车间主任和负责落地的IT工程师。很多人把MES想成一个大黑匣子其实加工装配类MES的骨架一张工单流转表就能说清楚。2. SimpleMES的数据建模核心物料、多级BOM和工艺路线怎么落到一张工单上2.1 基于若依框架的MESSimpleMES把哪些能力白送给了你若依框架在Java技术栈里普及度很高基于若依框架的MES项目一搜一大把SimpleMES是其中偏向加工装配场景的一种开源实现。选这个底座的直接好处是用户管理、角色权限、菜单管理、操作日志、定时任务、代码生成器这些通用模块齐全不用从零写。你做MES时最费时间的是业务建模而不是用户登录和按钮权限这些重复工作。RuoYi-Vue的技术栈是Spring Boot加Vue加MyBatis加MySQL招人容易二次开发门槛低。很多车间没有专职架构师找一个能写SSM的工程师就能维护这是我推荐它在中小厂落地的主要原因之一。再加上若依自带定时任务和缓存监控MES里最常用的工单超时预警、设备状态心跳检测都能直接挂在框架的调度器上不需要额外引一套任务系统。2.2 物料主数据先理清三件事编码、单位、批次加工装配车间的物料特点是层级多半成品要过好几道工序才变成成品。物料主数据如果建不好后边的BOM展开、齐套计算、报工入库全是错的。我一般建议在建SimpleMES的基础数据时先把这三件事定死。第一物料编码全局唯一禁用中文名当主键。第二物料类型的边界要清楚原材料、半成品、成品三类区分开装配场景中半成品是否要建独立物料编码要在项目启动会上拍板。第三批次管理默认开启哪怕现在的库存量不大也要开。理由是装配场景的追溯诉求很强一旦客户投诉或者来料不良你要能从成品条码倒查到批次、供应商和加工记录没有批次字段这个追溯链就断了。物料主数据在SimpleMES里通常对应的建表逻辑如下CREATE TABLE mes_material ( material_id BIGINT AUTO_INCREMENT PRIMARY KEY, material_code VARCHAR(64) NOT NULL UNIQUE COMMENT 物料编码全局唯一, material_name VARCHAR(128) NOT NULL COMMENT 物料名称, material_type CHAR(1) NOT NULL COMMENT 类型1原材料 2半成品 3成品, unit VARCHAR(8) NOT NULL DEFAULT PCS COMMENT 基本单位, is_batch TINYINT NOT NULL DEFAULT 1 COMMENT 批次管理1开启 0关闭, safety_stock DECIMAL(12,2) DEFAULT 0 COMMENT 安全库存, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB COMMENT物料主数据;这里的关键参数是material_type和is_batch。类型会影响后续BOM展开时是否要继续往下拆批次管理建议生产型和贸易型的物料都开别为了省事关掉。单位这里建议统一到最小计量单位装配车间经常混用“套”和“件”如果不统一报工数量换算会踩坑。导入物料时常见的做法是先把Excel模板导出清洗后通过若依代码生成器做成的导入功能批量入表。要注意Excel里如果编码重复MySQL的唯一索引会直接抛错数据库层面加一道保险比什么都管用。2.3 装配场景的关键配置多级BOM展开与工艺路线绑定装配BOM的难点不是建父子关系而是变更多。今天换了一个供应商螺栓规格变了整条装配路径的物料需求都要跟着变。SimpleMES里通常把BOM和工艺路线分开维护工单创建时选择“BOM版本加工艺路线版本”的组合再取组合后的快照数据。这样老工单继续走老BOM新工单自动用新版本不会互相污染。多级BOM展开的SQL在MySQL里可以靠递归CTE完成。加工装配的叶子节点可能是采购件也可能自加工件但齐套计算只关心最底层物料需求所以要递归展开到叶子。我给一个可以直接调试的版本-- 按BOM版本递归展开到叶子物料并折算成根节点的用量系数 WITH RECURSIVE bom_flat AS ( SELECT material_id, parent_id, qty, 1 AS level FROM mes_bom_item WHERE bom_revision_id 1001 AND parent_id 0 UNION ALL SELECT c.material_id, c.parent_id, c.qty * p.qty, p.level 1 FROM bom_flat p JOIN mes_bom_item c ON c.parent_id p.material_id WHERE c.bom_revision_id 1001 ) SELECT material_id, SUM(qty) AS unit_qty FROM bom_flat GROUP BY material_id;这段SQL的逻辑是先取根节点然后逐层往下子项的用量乘以父项的累计系数。bom_revision_id是BOM版本的外键parent_id 0表示根节点。展开后得到的unit_qty是单位成品的物料需求量后面跟工单数量相乘就得到总需求。注意递归CTE在MySQL 8.0以上才支持如果是5.7要么换写法或者升级数据库这一点会在老车间部署时经常发生提前确认版本能省不少麻烦。工艺路线相对简单一张表就能维护CREATE TABLE mes_route_process ( id BIGINT AUTO_INCREMENT PRIMARY KEY, route_id BIGINT NOT NULL COMMENT 工艺路线ID, process_seq INT NOT NULL COMMENT 工序顺序从10开始, process_name VARCHAR(64) NOT NULL COMMENT 工序名称如装配、点焊、老化, workcenter_id BIGINT NOT NULL COMMENT 工作中心ID关联产线或工位, standard_hours DECIMAL(8,2) COMMENT 标准工时小时, is_check TINYINT DEFAULT 0 COMMENT 是否必检工序1是 0否 ) ENGINEInnoDB COMMENT工艺路线工序表;process_seq我建议按10、20、30递增编号中间要插工序时不用重排。有了这张表工单创建时按process_seq排序批量生成工序实例后续报工就是逐个工序走状态逻辑就清晰了。很多MES说明书里把“工单生成的同时复制工艺路线”叫工序实例化这是SimpleMES从建模走向执行最关键的一步。3. 从工单下达到完工入库SimpleMES的工序流转与报工逻辑3.1 一张工单在SimpleMES里怎么走完五步工序流转是加工装配MES的执行主线操作工所有的操作都围绕“当前工单当前工序”展开。常见流程分五步创建工单、下达车间、工序开工、报工、完工入库。创建工单的时候系统根据产品和数量的组合自动带出BOM版本、工艺路线版本并生成一批工序实例每道工序初始状态是等待开工。下达车间后班组长才能看到任务并派工到产线。每道工序等待开工不等于设备正在生产真正的开工动作是操作工扫码确认“我开始干了”这个时间点就是工时采集的起点。报工后系统校验合格数、不良数同时判断是否还有下一道工序全部工序完成后工单自动进入入库候选状态。这套流程的价值在于你不用额外安装设备采集硬件也能先把工序级数据采集起来。对装配车间来说设备自动化程度参差不齐人员动作数据比设备数据更重要。3.2 工单条码规则怎么定从4321这个编号说起标题里的4321我理解是一套工单编号规则的典型示例。实际编码结构可以拆成“4位产品系列 3位工艺版本 2位产线代码 1位班次代码”合起来就是一个可读、可追溯的工单号。关键不是数字位数而是扫码后系统能解析出产品、版本、产线和班次信息。生成工单号的Java代码也可以写得很直接public String buildWorkOrderCode(Product product, ProcessRoute route, String lineCode, Integer shiftCode) { // 4321规则示例产品系列4位 工艺版本3位 产线2位 班次1位 String productCode StringUtils.leftPad(product.getSeriesCode(), 4, 0); String routeCode StringUtils.leftPad(String.valueOf(route.getVersion()), 3, 0); String linePart StringUtils.leftPad(lineCode, 2, 0); String shiftPart String.valueOf(shiftCode); return productCode routeCode linePart shiftPart; }参数说明seriesCode是产品系列编码不是完整物料编码控制在4位只做标识不做含义解析。route.getVersion()是工艺路线版本号3位足够用到999个版本。lineCode建议直接用厂区编号不要用产线中文名避免条形码里出现中文导致扫码枪乱码。班次代码用1、2、3对应早中晚班。这里有一个很容易忽略的坑编码里不要加上日期日期变体天然每天不同会导致返工追溯困难。日期单独在数据库字段里保存扫码查询时传参即可不要把动态日期拼进条码。车间师傅扫了条码也看不出日期反而容易扫错工单。3.3 齐套检查装配车间最刚需的一张缺料清单装配场景的典型痛点是开工前发现缺料生产已经停了才发现仓库少一个贴片电容。齐套检查必须在工单下达前跑一次逻辑也很直白根据工单数量和BOM展开结果算需求减去可用库存大于零的就是缺料。-- 齐套检查需求数量减去可用库存返回缺料清单 WITH RECURSIVE bom_flat AS ( SELECT material_id, qty, 1 AS level FROM mes_bom_item WHERE bom_revision_id #{revisionId} AND parent_id 0 UNION ALL SELECT c.material_id, c.qty * p.qty, p.level 1 FROM bom_flat p JOIN mes_bom_item c ON c.parent_id p.material_id WHERE c.bom_revision_id #{revisionId} ) SELECT f.material_id, f.qty * #{orderQty} AS demand_qty, IFNULL(s.available_qty, 0) AS available_qty, f.qty * #{orderQty} - IFNULL(s.available_qty, 0) AS shortage_qty FROM (SELECT material_id, SUM(qty) AS qty FROM bom_flat GROUP BY material_id) f LEFT JOIN mes_material_stock s ON s.material_id f.material_id HAVING shortage_qty 0;这个查询的核心在available_qty字段。你库存表里的账面库存和可用库存一定不要混用。账面库存包括已经预留给其他工单的量如果直接拿账面数去算齐套就会得出虚假的“已齐套”真正开工时又缺料。我一般在mes_material_stock表里加一个reserved_qty字段可用库存等于库存总量减去预留量齐套检查只认可用库存。这是很多MES实施中后期才补的补丁建议一开始就按这个逻辑建表。3.4 报工事务为什么不能只写一条报工记录工序报工看着简单但它是MES里最容易出数据事故的地方。常见错误是只往报工表插入一条记录然后不管在制数量。正确的做法是报工插入和工序数量更新必须在同一个数据库事务里否则报工成功但工序状态没变在制数量就变成一笔糊涂账。/** * 工序报工写报工记录并更新工序完成数量 */ Transactional(rollbackFor Exception.class) public void reportProcess(ReportDTO dto) { WorkOrderProcess wp workOrderProcessMapper.selectByIdForUpdate(dto.getProcessId()); // 状态校验只有运行中的工序才允许报工 if (!RUNNING.equals(wp.getStatus())) { throw new BizException(工序状态不是运行中不能报工); } // 防错累计合格数量不能超过工单计划数量 BigDecimal finishedQty reportMapper.sumQualifiedQty(wp.getId()); if (finishedQty.add(dto.getQualifiedQty()).compareTo(wp.getPlanQty()) 0) { throw new BizException(报工数量超出工单剩余数量); } // 写入报工记录同时更新工序完成数量 reportMapper.insert(dto); wp.setFinishedQty(finishedQty.add(dto.getQualifiedQty())); // 全部完成则工序状态流转为已完成 if (wp.getFinishedQty().compareTo(wp.getPlanQty()) 0) { wp.setStatus(FINISHED); } workOrderProcessMapper.updateById(wp); }这段代码有三个关键细节。第一selectByIdForUpdate加行锁防止两个操作工同时扫同一道工序重复报工。第二报工数量与工序余量做校验这一步是“防错”装配车间常见的错装漏装问题通过数量校验能挡住一部分。第三Transactional保证报工记录和工序数量一起成功、一起失败不会出现报工了但数量没涨的情况。3.5 完工入库与后道工序解锁一个工单的最后一道工序报工完成后系统要自动把产品状态改成待入库同时对下道工序解除锁定。这是通过报工后的事件触发实现的而不是让操作工手动去点击“完工确认”。我见过很多项目在每一个环节都让人去点按钮操作工嫌烦最后直接不点数据就是死的。常见的实现方式是报工事务成功提交后通过Spring的事件发布机制监听工序完成事件然后自动判断process_seq是否为该工单最大的工序如果是就更新工单状态为完工。你要在报表上查“今日完工量”直接查这张工单状态即可不要在Excel里再汇总一遍。4. 基于若依框架的权限配置车间里谁该看什么一个按钮都不能多4.1 三套常用角色菜单操作工、班组长、计划员MES上线后最让车间反感的不是系统慢而是屏幕上堆满了和自己无关的菜单。SimpleMES基于若依框架的权限体系可以很好地按角色裁剪菜单。我一般建议分三套默认角色模板。操作工只保留“我的任务、工序报工、不良上报”班组长增加“工单查询、齐套检查、异常处理、人员派工”计划员增加“BOM维护、工艺路线维护、工单创建、库存查询、报表中心”。车间主任和管理层可能还要看“效率看板”但这类角色建议后置等数据稳定了再开。在若依框架里菜单权限通过perm字符串控制角色配菜单用SQL就能批量完成-- 给班组长角色批量绑定菜单权限 INSERT INTO sys_role_menu(role_id, menu_id) SELECT r.role_id, m.menu_id FROM sys_role r, sys_menu m WHERE r.role_key workshop_leader AND m.perms IN ( mes:workorder:list, mes:material:available, mes:exception:handle, mes:report:list );这段SQL用了SELECT ... FROM sys_role, sys_menu的笛卡尔积加条件过滤方式避免逐条手写INSERT。真正执行时可以把role_key换成你系统里实际的角色标识。菜单权限的粒度建议控制到按钮级操作工界面上连“删除工单”的按钮都不要出现因为越权的操作人员点错一次整条工单数据就乱了。4.2 数据权限让班组长只看到自己那条产线菜单权限控制能不能进某个页面数据权限控制进了页面能看哪些行。SimpleMES里常见的诉求是A线的班组长看不到B线的工单和报工记录。若依框架自带DataScope注解可以在查询前自动拼接数据过滤条件。/** * 工单查询列表数据权限自动过滤产线 */ DataScope(deptAlias d, userAlias u) public ListWorkOrder listWorkOrder(WorkOrderQuery query) { return workOrderMapper.selectWorkOrderList(query); }对应的Mapper XML里要预留数据权限拼接位置select idselectWorkOrderList parameterTypeWorkOrderQuery resultTypeWorkOrder SELECT w.order_id, w.order_code, w.product_id, w.plan_qty, w.status FROM mes_work_order w LEFT JOIN sys_dept d ON d.dept_id w.dept_id where if teststatus ! null AND w.status #{status} /if ${params.dataScope} /where /select${params.dataScope}是若依框架数据权限解释器自动拼接的SQL片段。关键是工单表上要挂dept_id这个部门对应实际产线不能随便挂一个行政部门的ID。如果工单表里没设计dept_id字段数据权限就无从谈起这是建模阶段就要预留的字段而不是上线后补。数据权限是MES项目里争议很大的功能建议上线第一天就开启后期再开会让工人觉得系统在“突然限制自己”反而不配合。4.3 字典参数与基础配置合格率阈值、工时版本、不良代码若依框架的字典管理可以直接复用。MES里最典型的字典是“工序状态”和“不良原因”。工序状态我建议就用四个等待开工、运行中、已完成、已关闭。太多状态会让操作工不知道选哪个太少又无法表达返工等场景。不良原因代码要提前跟质检部门对齐装配场景常见的有错装、漏装、外观划伤、扭矩超差、尺寸超差这五类宁可先少后补也不要让人在文本框里随手敲中文。合格的MES说明书应该把每个字段的解释、可选值和流转规则写清楚这比写代码重要得多。字典配置步骤很简单在若依管理后台的“字典管理”里新建字典类型mes_wo_status然后添加字典数据。这些数据在工单下拉框、报表筛选项里会自动生效不需要改前端代码。5. 加工装配场景里最常踩的5个坑按现象、原因、解决方案排查5.1 报工了但WIP在制数量对不上现象上午报工了120件下午查在制数量还是0或者变成了负数。整个车间在制数没人敢信。原因报工表和工序状态更新不在同一个事务里半路失败导致报工记录写进去了但工序数量没更新更常见的是直接在工单表存了一个冗余的wip_qty字段报工加一笔、入库减一笔中间任何一步漏了就对不上。解决不要单独存WIP字段在制数量永远通过“累计报工数量减去累计入库数量”实时算出来。报工、质检判定、入库、状态更新全部放进一个事务。每周让班组长抽查三个工单的在制数和现场实物进行比对坚持两周数据可信度就上来了。5.2 齐套检查显示齐套开工还是缺料现象工单下达前齐套检查通过了真正开工时仓库发不出料。原因齐套计算用了账面库存而不是可用库存。账面库存没有扣掉已经预留给其他工单的数量甚至没有扣掉已经被品质冻结的来料不良库存。解决库存表增加reserved_qty和frozen_qty两个字段。可用库存总库存-预留-冻结。同时把齐套检查从“即时查询”改成“工单下达时生成快照”缺少的物料锁定需求后续采购到货后自动释放预留。操作上仓库每次做库存异动时都要在系统里同步更新预留量这一步做不到齐套检查永远不准。5.3 扫码枪输入项目标题时自动跳过字符现象操作工扫工单条码输入框里偶尔少一个字符或者最后多一个回车符导致查询不到工单。原因扫码枪在键盘仿真模式下中文输入法会截断字符另外扫码枪默认的结束符是回车键看系统有没有自动把回车转成查询触发。输入框没有去空格和回车处理也是常见原因。解决扫码枪配置里把工作模式设置为“键盘仿真回车后缀”成本低兼容性好。代码层面对条码做统一处理接收到输入框的值先trim()掉首尾空白再去掉结尾的\r\n。查询按钮用回车事件触发这样扫码和手动回车都能得到一致结果。不要改用USB串口模式Windows和Linux的驱动配置差异会让你多踩三天坑。5.4 修改BOM后已下发的工单还在用旧版本但物料需求变了现象技术员改了装配BOM结果工单报工时物料需求全是错的要么多算要么少算。原因工单没有对BOM做版本快照BOM修改直接影响了在制工单。解决BOM表只做新增版本不做原地修改。每个工单创建时把BOM明细复制到工单BOM快照表后续查询物料需求都走快照表而不是JOIN最新BOM版本。这样做还有一个好处就是追溯历史工单时可以还原当时的BOM到底是什么样。这条准则同样适用于工艺路线工单一旦创建工艺版本不可变更除非显式做工序变更单。5.5 若依定时任务和MES轮询任务并发导致工序超时误报现象凌晨1点一批工单被自动标记为“超时”但是实际上班次是下午4点才结束。原因若依框架自带的定时任务默认每分钟扫描一次而MES工序超时检测任务也是独立调度的两个任务并发执行时超时检测读到了还没落库的班次结束事件。解决为超时检测任务补充“班次结束时间校验”逻辑只处理当前时间大于计划结束时间加缓冲时间的工单。在若依的调度管理里把两个任务的执行错开不要都放在整点。更重要的是给定时任务加上分布式锁避免多实例部署时重复触发。经验是MES里的定时任务一定要允许手动补跑否则一旦漏跑超时状态的数据补起来会非常费劲。6. 把SimpleMES从“记录系统”变成车间看板先盯住一条小时产出SQL很多MES项目死在上线三个月后没人看报表。要避免这个结局我的建议是不要一开始就做大而全的看板而是先盯住一条小时产出SQL。对车间主任来说今天现在这一刻产线干出了多少合格件比任何漂亮图表都管用。-- 按小时统计各工序的合格产出和折算标准工时 SELECT DATE_FORMAT(r.report_time, %Y-%m-%d %H:00) AS hour_bucket, wp.process_name, SUM(r.qualified_qty) AS qualified_qty, ROUND(SUM(r.qualified_qty * wp.standard_hours), 2) AS standard_hours FROM mes_report_record r JOIN mes_workorder_process wp ON r.process_id wp.id WHERE r.report_time NOW() - INTERVAL 24 HOUR GROUP BY hour_bucket, wp.process_name ORDER BY hour_bucket DESC, wp.process_name;要把这个查询跑起来前提是报工记录里带准确的时间戳并且每道工序实例上有standard_hours。很多实施项目把标准工时放在工艺路线表里工单工序实例没有复制一份结果报表只能按数量统计算不了效率。工序实例落库时把标准工时快照下来是我反复强调的一个点。报表稳定后可以算极简版OEE。口径不需要追求和教科书一致能用就行合格产出数量乘以标准工时除以设备可动工时。可动工时按班次时长减去计划停机时间。这样算出来的OEE有一个偏差但趋势是可靠的。对比每天的OEE波动再结合不良代码占比就能定位是哪个工序掉链子。等我回头看这些年做过的MES项目凡是能坚持三周核对小时产出数据的车间最后都把SimpleMES用成了真正管理的抓手凡是只看月报的都半途而废了。数据这种事你不能等它自己变准要拉着班组一起较真较真两三个礼拜大家才认账。希望帮到你。本文还有配套的精品资源点击获取
