简介面向制造业信息化负责人、MES项目选型及实施人员、车间管理者的一份PDF资料围绕智能制造与MES应用展开可帮助读者建立从智能制造内涵到MES落地执行的整体认知框架。内容依据e-works黄培博士的行业报告整理系统梳理了MES作为智能工厂枢纽需要解决的现场信息透明化、生产过程可追溯、资源配置优化等痛点并详细讲解MES与ERP、自动化设备、传感器及数字孪生、物联网、工业大数据等新兴技术的集成关系同时覆盖可视化排产、APS、无纸化、精益生产等应用热点。全包为1个PDF文件大小2.68MB便于下载后离线研读。目前已有160人学习浏览适合正在规划数字化工厂或准备实施MES的企业人员快速充电还可参考其中的智能制造市场热点、国内外MES供应商概况及e-works多年咨询案例辅助项目选型与推进。1. 智能制造与MES应用一份PDF让我重新梳理了车间数字化的落地顺序第一次拿到《智能制造与MES应用.pdf》时我以为又是一本把MES讲成“万能药”的教材。通读两遍后我改变了看法它没有停留在概念层而是直击车间里最常纠缠的问题——工单怎么流转、报工怎么算数、异常怎么处置。这份PDF适合两类人一类是刚接手MES选型的生产主管另一类是要跟车间打交道的开发人员。我试着从里面提炼出一套能直接落地的分析框架并结合目前主流的若依框架MES二次开发经验把这本资料拆成可执行的方法。下面是硬核部分先把边界说清楚再谈技术。2. MES的核心定位与若依框架的二次开发前提先分清你是在选型还是在做实施2.1 MES到底管什么从工单到报工的闭环MES的边界很多人跟ERP混着谈。ERP管的是“何日需要多少货”MES管的是“此刻这道工序用谁在设备上做了多少、合格没有”。这份PDF里反复强调“计划-执行-控制”三层模型ERP是计划层MES是执行层PLC/传感器是控制层。MES处在中间向上承接ERP的工单和物料需求向下采集设备状态和产量数据。没有MES时车间说“做了800件”账上可能还是“计划1000件”差异只有月底盘点才知道。有了MES从工单下达那一刻起每一个状态变化都会被记录。要把这个概念落到实际我一般会先做一张功能边界表避免团队在选型会上吵到失控。下面这张表是我读PDF后整理的可以作为立项时的初步依据层级系统典型功能输出物计划层ERP主生产计划、物料需求计划、采购订单生产工单执行层MES排产、派工、领料、工序报工、质检、异常管理、完工入库报工记录、质检单、完工记录控制层PLC/SCADA设备状态采集、参数下发设备数据、工艺参数判断一个功能应该放ERP还是MES标准很简单如果它要回答“某一天某个工位上发生了什么事”那就是MES的事。比如“订单交货期”是ERP的事“B线喷漆这个班次做了多少件”是MES的事。把这个边界画清楚后再去读PDF关于“生产建模”的部分思路就通顺多了。实际操作时我会带着这张表格跟车间主任一条一条对问“这个流程现在谁在盯”他答不上来的就是MES要补的。很多团队一上来就画菜单树结果把MES做成了“工单登记表”根源就在于没先定义执行层的东西。在若依框架里做MES二次开发我发现很多人一上手就写CRUD结果把MES做成了“电子Excel”。正确的姿势是先把业务对象梳理成“工单-工序-资源-人员-物料”五个主数据然后对应建表。若依的权限模型只能覆盖“谁能看菜单”管不了“谁能在某个工位上报工”这需要在业务表里增加部门或岗位维度。后面第四章我会讲具体的数据模型设计这里先记住一句话MES的差异不在界面而在状态机和数据闭环。2.2 若依框架MES的常见形态后台权限与数据模型的复用边界若依框架是目前国内开源后台管理里最常被拿来当MES基座的框架之一。它自带用户、角色、部门、菜单、操作日志、字典管理省去了RBAC和代码生成器的时间。业界很多“若依MES”项目就是这么拼出来的若依提供后台底座业务团队在上面加车间模块。但这里有一个必须清醒的点若依帮你搞定了“后台管理”没帮你搞定“车间执行”。车间执行的关键是数据从哪来、状态怎么变、异常怎么处理。用下表来对比若依自带能力和MES需要补的能力能力域若依自带MES需要补充用户与权限菜单权限、数据权限支持部分按车间/产线/工位的资源权限流程状态无状态机只有CRUD工单状态流转、工序状态流转数据采集无集成PLC、扫码枪、电子秤报工事务无防重复提交唯一约束异常处理无异常登记、升级、自动通知看板无实时产量、不良率、稼动率选型时我建议团队先回答三个问题第一你们的车间生产是离散制造还是流程制造这决定了工序模型的设计。离散制造按工单拆工序流程制造按批次和配方两种模型的表结构完全不同。第二现有设备有没有联网数据如果全靠人工报工MES就类似电子工单不要过度设计。第三是不是需要与ERP对接对接字段和时机要先谈好否则后续改起来非常贵。若依框架不是MES的银弹但它能让你把精力集中在业务核心上。拿这份PDF来说里面讲“生产工单状态”一般包括“创建、下达、开工、完工、关闭”。若依框架里没有现成的状态机但我可以用自定义注解加AOP来统一处理状态变更日志而不是在每个业务方法里手动写update语句。这样后端代码会干净很多。另外若依的“数据权限”支持自定义你可以把车间主任的数据范围限制到本车间但不能精确到“某条产线的某个工位”所以需要在业务表中增加“产线ID”字段再用行级权限过滤。这一步很多人忽略等上线后才发现跨车间能互相看到数据。我的习惯是在开工第一周就写一个“权限检查SQL”模拟不同角色的查询把越权数据全部扫出来比等用户投诉再排查强得多。这一章的核心结论是MES的应用边界必须先用业务对象画清楚再映射到系统能力。不要因为用了若依就认为MES是“低代码搭个界面”反之也别觉得MES一定要上自动化设备采集很多车间靠扫码报工就能解决90%的问题。3. 把PDF读成实施手册从业务调研到功能清单的转化方法3.1 先画业务流程图再对功能树很多团队拿到MES以后第一件事是找人开发“工单管理”菜单结果做出了一个“电子Excel”车间根本不买账。我读这份PDF时印象最深的一段话是MES实施的第一成果不是系统而是一张业务流程图。只要流程错了系统做得越漂亮错得越厉害。具体的转化步骤我会这么走。第一步选一条典型产线比如组装线或机加工线跟班组长一起走一遍实际流程从ERP工单来到车间后由谁接收怎么拆分到工序谁来派工员工做完后如何记录数量不良品怎么处理最后如何报完工。把这些动作按顺序写下来不要跳过任何“打电话问一下”的隐性环节。下面是一个离散制造车间的简化流程文本ERP工单下发 - 车间计划员审核 - 系统拆分工序计划 - 产线组长派工到工位 - 员工扫码开工 - 加工完成 - 扫码报工良品数/不良品数 - 质检员抽检 - 合格则流转下一工序不合格则发起异常单 - 末工序完工 - 入库这个文本流程足以让团队统一认知。第二步把流程中的每个动作映射成功能点审核对应“工单审核功能”拆分对应“工序计划”派工对应“派工单”报工对应“工序报工”异常单对应“异常管理”。第三步把这些功能点合并成功能树比如“生产管理 工单管理 工单审核”这样就能输出一份需求清单。为什么一定要先画流程因为我在若依框架里见到太多“菜单先行”的失败案例菜单长得和ERP一样但车间不用。实际上MES的所有业务动作都围绕“工单-工序-报工”这条主线。只有把流程中每个节点的输入、输出、时间要求、责任角色定义清楚功能树才有意义。这个步骤相当于把PDF里的理论翻译成车间听得懂的话。我一般还会用不同颜色标注“当前纸质流程”和“目标系统流程”差异点就是实施要重点攻克的地方比如原来靠口头传达的换料通知系统里就要变成一条自动推送的消息。3.2 用一张参数表把生产异常处理规则定下来异常处理是MES里最容易“翻车”的模块。很多系统有异常登记功能但异常单提交后石沉大海原因是没有预先定义处理规则。这份PDF提到“异常闭环”概念发现异常 - 记录 - 响应 - 处理 - 关闭每一步都要有角色和时限。我的做法是在需求阶段做一张异常处理参数表让生产、质量、设备三方一起确认。这张表不需要覆盖所有异常先抓最影响产出的三类缺料、宕机、质量超标。异常类型触发条件默认处理角色响应时限影响工单状态物料缺料领料数量不足或未按计划到达物控员30分钟工单暂停设备故障设备停机超过15分钟维修工1小时当前工序暂停质量不良不良率超过5%或连续3件不良质量工程师2小时工单转待评审操作未报工超过规定报工时间1小时班组长当天工单预警这张表的作用不是写进文档就完事而是要落成系统参数每个异常类型对应一个字典处理角色对应若依的角色ID响应时限用于超时提醒影响状态用于自动更新工单状态。这样做的好处是当现场出问题时系统不是“记一笔”而是自动把消息推给责任人并暂停或置罥相关工序。在若依框架里实现时我通常会把这套规则放到“异常类型表”和“异常处理配置表”中而不是硬编码在业务代码里。比如异常类型表中包含“异常编码、名称、处理角色ID、响应时限、影响状态”这样后续改规则不用改代码只要改配置。这个思路也吻合PDF强调的“柔性制造”理念——规则可配置系统才有应变能力。注意若依自带字典管理可以直接复用但“响应时限”这类带数字的属性建议单独建配置表因为字典值存字符串导致排序和比较都很别扭。另外处理角色要填角色ID数组因为现实里异常会升级到主管需要在配置表里加“升级角色ID”字段。3.3 从工序计划到报工的字段设计报工字段的设计直接决定月底报表能不能算清工资。我在车间调研时发现很多老班组长交上来的“工时”是臆造的因为系统里没有“设备编号”“工位编号”这些维度无法核对。这份PDF里的报工示例字段我把它简化成下表的清单字段名类型说明必填工单IDvarchar(32)关联ERP工单或内部工单是工序IDvarchar(32)当前工序唯一标识是设备IDvarchar(32)实际加工设备否工位IDvarchar(32)实际工位否操作工IDvarchar(32)关联用户表是计划数量decimal(10,2)本工序计划数量是良品数量decimal(10,2)合格入库数量是不良品数量decimal(10,2)不合格数量是不良原因编码varchar(32)关联不良原因字典否报工时间datetime系统自动生成是字段设计的核心原则是“采集一次多处复用”。比如“设备ID”不仅要用于产量统计还要用于设备稼动率计算所以要保证它来自设备主数据而不是报工页面手填。这里我踩过坑拿着Excel导入设备时没有做唯一性校验导致同一个设备在报工记录里出现“CNC-01”和“CNC-01 ”带空格两个版本报表直接分裂。从那以后所有主数据导入我都用“编码名称”的联合去重甚至先清洗空格和全角字符。在设计字段时我还会额外加一个“业务唯一键”字段比如“工序报工唯一键 工单ID 工序ID 设备ID 操作工ID 报工时间截”用来防止重复提交。这个字段配合数据库唯一索引比在代码里判重要可靠得多。如果你用的是若依自动生成的代码要记得在实体类中增加该字段并在数据库表上建立唯一约束否则并发请求下两条一样的报工会同时插入。还有一点报工时间截最好由后端统一生成不要信任前端时间因为车间电脑的时钟经常不准。4. 基于若依框架搭建MES的技术要点数据模型、接口与权限4.1 数据库表设计用若依的部门表延伸车间-产线-工位若依的sys_dept表是树形结构天然适合组织映射。我在MES项目里一般让“部门”层级对应“公司-工厂-车间”然后单独建一张“产线表”和“工位表”通过车间ID关联。为什么不直接全部塞进部门表因为产线和工位不是行政组织是资源它们有产能、状态等属性塞进去会让权限控制变得奇怪。下面以MySQL语法为例给出产线表和工位表的简化设计。-- 产线扩展表一个车间有多条产线 CREATE TABLE mes_production_line ( line_id BIGINT PRIMARY KEY AUTO_INCREMENT, line_code VARCHAR(32) NOT NULL UNIQUE, -- 产线编码如 L_A01 line_name VARCHAR(64) NOT NULL, workshop_id BIGINT NOT NULL, -- 关联 sys_dept.id表示所属车间 capacity_per_hour DECIMAL(10,2) DEFAULT 0, status CHAR(1) DEFAULT 0, -- 0可用 1维修 create_by VARCHAR(32), create_time DATETIME, FOREIGN KEY (workshop_id) REFERENCES sys_dept(id) ); -- 工位表一条产线上多个工位 CREATE TABLE mes_workstation ( ws_id BIGINT PRIMARY KEY AUTO_INCREMENT, line_id BIGINT NOT NULL, -- 关联产线表 ws_code VARCHAR(32) NOT NULL, ws_name VARCHAR(64) NOT NULL, device_id BIGINT NULL, -- 关联设备主数据可选 is_key_point CHAR(1) DEFAULT 0, -- 是否关键工序 status CHAR(1) DEFAULT 0 );这段SQL的逻辑先定义产线再定义工位两者通过line_id关联车间归属通过workshop_id指向sys_dept。这样用若依自带的用户管理给班组长分配“车间数据权限”时只需要在SQL里JOIN mes_production_line的workshop_id。注意line_code和ws_code都加了唯一约束这是防止Excel导入重复数据的第一步。在设计时我把“设备”单独建表而不是放在工位上因为设备可能被调拨到不同工位。字段说明capacity_per_hour用于排产估算status用于设备/产线状态看板。这里要特别注意外键的级联删除策略工位产能数据会被生产记录引用所以不要物理删除只用status标记停用否则你把一个工位删了历史报工数据全变孤儿记录。另外workshop_id关联sys_dept时要保证sys_dept的dept_type字段能区分“车间”和“公司”否则会关联到错误节点。4.2 工序流转与报工的接口设计报工接口是MES的高频事务生产高峰期每秒可能有几十个请求。若依框架的Controller层默认是基于单表的增删改查如果直接用“先查工单状态再更新工单数量再插入报工记录”这种非原子操作并发情况下必然出现超卖。我的做法是报工操作放到一个Service方法里用数据库事务控制并且在业务表中加唯一约束。给出一个简化版的Java接口逻辑Transactional public AjaxResult reportWork(ReportWorkDTO dto) { // 1. 生成业务唯一键工单ID工序ID设备ID操作工ID报工时间截 dto.setUniqueKey(buildUniqueKey(dto)); // 2. 校验工单和工序状态只有“已下达”且当前工序为待报工状态才允许 WorkOrder wo workOrderMapper.selectById(dto.getOrderId()); if (wo null || !2.equals(wo.getStatus())) { return error(工单不存在或状态不允许报工); } // 3. 插入报工记录依赖数据库唯一索引防重复 try { reportMapper.insert(dto); } catch (DuplicateKeyException e) { return error(请勿重复提交报工数据); } // 4. 更新工序完成数量 processMapper.updateCompletedQty(dto.getOrderId(), dto.getProcessId(), dto.getGoodQty()); // 5. 判断是否所有工序完工是则更新工单状态 updateOrderStatusIfNecessary(dto.getOrderId()); return success(); }这个接口用Transactional保证步骤3到5要么都成功要么回滚。参数DTO里必须包含orderId、processId、deviceId、operatorId、goodQty、badQty。要点在第2步状态校验不能放在前端因为接口可以被绕过。第3步的捕捉DuplicateKeyException是最后一道防线依靠数据库唯一索引来兜底。我一般把唯一索引建在“order_id process_id device_id operator_id report_time”上但报工时间可能精确到秒同一秒内同一人同一设备对同一工序手工报工两次会被视为重复——这是合理的因为正常情况下一个工单同一工序只报一次。如果现场有“补报”需求比如夜班结束后批量录入那么唯一键应该去掉operator_id或改为“报工批次号”否则会挡住合法的补报数据。这个细节要跟车间确认清楚是每完工一件报一件还是批次完工后统一报不同模式对应不同的唯一键粒度。还有一个隐藏坑若依框架自带的事务管理基于Spring如果我们在Service里捕获DuplicateKeyException事务不会自动回滚因为异常已经被捕获了。所以我建议在catch块里主动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()否则后续步骤虽然不回滚但已经插入的报工记录会保留状态更新却可能失败导致数据不一致。4.3 数据看板与报表别在框架里硬写SQL若依有个很常用的设计是后台列表页查询但MES的看板需要实时汇总直接在业务表上写sum查询会拖垮数据库。我建议分两类处理事务明细表只保留最近一周的实时数据汇总看板数据放到一张“生产统计汇总表”中由定时任务计算。下面是一个按小时统计产量的SQL示例用于驱动看板-- 按车间、产线、小时统计良品数结果写入统计表 INSERT INTO mes_prod_statistics ( stat_date, hour_no, line_id, good_qty, bad_qty, create_time ) SELECT CURDATE() AS stat_date, HOUR(report_time) AS hour_no, ws.line_id, SUM(CASE WHEN r.good_qty 0 THEN r.good_qty ELSE 0 END) AS good_qty, SUM(IFNULL(r.bad_qty, 0)) AS bad_qty, NOW() FROM mes_work_report r JOIN mes_workstation ws ON r.ws_id ws.ws_id WHERE report_time NOW() - INTERVAL 1 DAY GROUP BY ws.line_id, HOUR(report_time);这条SQL的逻辑从报工明细表中按产线和小时聚合等待写入统计表。注意这里用了CURDATE()和HOUR()函数在MySQL中效率尚可但如果报工表非常大建议在前一天定时任务中只处理“上月”的数据。参数说明mes_work_report是报工流水表mes_workstation是工位表ws.line_id用于关联产线。执行频率建议每30秒一次而不是每次都跑全表。踩过的一个坑是使用HOUR(report_time)做分组时如果车间跨天23:00到01:00的数据会落在不同的stat_date和hour_no中看板会产生断点。解决办法是统计时用“班次”维度替代小时维度同时存储班次开始时间。另外不要用若依自带的代码生成器直接生成“看板列表”生成的查询会带分页和排序看板刷新会产生大量无意义的SQL日志把网关都刷爆。我给看板单独建一个只读数据源跟业务库隔离。这样即使看板SQL写得很重也不会影响前台正常报工。5. 避坑与常见问题排查车间上线MES的五个典型翻车点5.1 现象工单状态不同步常见场景是上午10点计划员在ERP里下达了工单MES里也生成了但过了2小时产线已经开动MES工单还停在“已下达”导致后续报工全部被拦截。还有更隐蔽的MES里工序已经完工了但ERP工单还是“执行中”月底对账时两边数量对不上。原因通常有两个一是两个系统之间的状态同步依赖定时任务任务失败后没有重试机制二是MES内部更新状态时只更新了工序表没更新工单主表。比如报工方法里只调用了processMapper.updateCompletedQty而工单表的status字段没有联动修改。解决方法是所有工单状态变更都必须走统一的状态机Service并记录状态变更日志定时任务加失败重试同步一旦失败要输出异常邮件。我实际项目中碰到过原因是若依的定时任务线程池被某个慢SQL卡死后续任务全部堆积。排查时可以看任务日志确认上一次同步时间距现在多久。从那以后我要求每个定时任务必须设置超时时间并且把单独工单状态同步改成按批次批量同步速度提升了一个量级。另外状态同步要加“对账接口”每天凌晨比对一次ERP和MES的工单状态把不一致的清单拉出来让人工处理。5.2 现象报工数据重复提交现场最典型的情况是员工在触摸屏上报工时手指点了一下“确认”没反应又点了一下结果生成两条一模一样的报工记录产量直接翻倍。如果是夜班交接员工自己都没注意等到月底对账才发现数量超了。原因是前端按钮没有做防重复点击后端接口也没有幂等控制。有人以为前端按钮置灰就万事大吉但车间网络差请求超时会自动重发这时候前端状态已经恢复后端的重复请求照样执行。解决策略分三层第一前端在点击提交后把按钮置灰并显示loading同时禁用触摸屏的双击事件第二后端在接收报文时先查Redis里是否已有该messageId有就直接返回上一次结果第三数据库表加唯一索引兜底防重。第三层最重要也是最后防线。我在若依里实现时还额外写了异常处理器把DuplicateKeyException翻译成“请勿重复提交”而不是给用户弹出500错误。注意唯一的索引字段不要用可空列因为MySQL下NULL值不参与唯一性约束防重会失效。这个问题困扰了我很久排查时发现字段在Excel导入时没填值导致同一工单被重复报了很多次。5.3 现象看板数据延迟车间的大屏显示“今日产量”从下午两点就没变过但报工界面一直有数据在增加。重启一次服务看板数据又更新了过一会儿又卡住。这种问题在我经历的项目里出现过三次。原因是定时统计任务把全量的报工表跑一遍数据量一大单次执行就要十几分钟下一次任务启动时上一次还没跑完线程池一塞整个调度队列就堵住了。另外大屏前端用的定时刷新如果写在浏览器标签页里电脑休眠后定时器会停止恢复后也不会自动重新拉数据。解决方法是把全量统计改成增量预聚合每5分钟只统计上一时段新增的数据写入统计表同时用WebSocket推送代替前端轮询。WebSocket断开后要自动重连否则一次短暂的网络抖动就会让大屏永久沉默。具体到SQL需要确保report_time和line_id上有联合索引否则增量查询也会全表扫。还有一个建议看板数据不要直接查业务表而是查统计表。统计表可以做保留策略比如保留3年但业务流水表只保留几个月定期归档。我在一次项目实施中就是因为统计SQL里少了“where report_time last_run_time”又把全表扫了一遍差点把生产库拖垮。从那以后我的统计任务模板里强制带“last_stat_time”参数每次运行都记录。5.4 现象用户权限混乱车间C的员工打开系统居然能看到车间A的工单甚至能修改别人的报工数量。质检员查出不良后想锁定工单却发现自己没有权限按钮找管理员又耽误了半天。原因多半是第一若依默认的数据权限没有配置或者配置了但Mapper的SQL没有带DataScope第二给用户分配了“超级管理员”角色一劳永逸但后患无穷第三自定义Mapper用了多表JOIN若依的数据权限注解只对主表别名生效子表数据没被过滤。解决步骤第一步收回超管角色只保留必需的运维账号并且强制开启双重认证。第二步在工单表增加dept_id字段并在查询Mapper的SQL头部写上DataScope(deptAlias wo)。第三步把所有涉及工单、报工的查询统一收到一个带权限的公共Service里禁止团队成员各自写Mapper。第四步上线前用测试账号跑一遍“跨车间越权”的用例。我在项目里发现若依的数据权限有个细节它会在SQL外直接拼接“and wo.dept_id in (...)”字符串但如果SQL里已经有“and wo.status 1”且后面还有括号拼接位置可能错乱。所以建议Mapper里的SQL只保留一层结构不要嵌套子查询。权限规则是账面上的事越早越严格越好上线后再推倒重来非常伤。5.5 现象系统上线后没人用最严重也最容易被忽视的翻车点系统上线一个月登录人数屈指可数报工数据全是文员事后补录的PDA和扫码枪挂在墙上吃灰。业务板块上的工单状态永远是“已创建”没有“执行中”的过程数据。原因是系统增加了工人的作业负担。比如报工页面要填8个字段还要从下拉框里找设备编号比原来在纸质流转卡上画勾慢得多又比如工位电脑摆得远工人来回走动浪费时间还有一种情况是系统没有给工人带来任何好处只像一个监控工具谁都不愿意配合。解决方法是上线前一定要做“岗位级”确认跟班组长和操作工一起设计报工页面尽量做到“扫一次码自动带出工单、工序、设备只填良品数和不良数”。把触摸屏或PDA放在工位伸手可及的位置按钮做大减少操作层级。同时把实时产量投到车间电视看板上让工人看到自己班组的产量排名。技术不是核心让现场感觉“系统是帮手而不是监工”才是。如果条件允许把报工效率跟计件工资挂钩工人自己就会主动用。我在一个紧固件车间里把报工时间从原来的“每件填3个下拉框”改成“扫码枪扫一次自动计时”上线第二天产能报表就活了。那一次我意识到车间的人不是抗拒系统是抗拒那些让他们多干活少拿钱的设计。6. 进阶验证用三条SQL验证MES数据闭环是否真的打通系统上线两周后我建议用三条SQL来自查数据闭环是否打通。第一工单完工数量核对选择一批已经关闭的工单统计每个工单在报工表中“良品数之和”跟ERP的完工数量比对。SELECT w.order_code, w.plan_qty, (SELECT IFNULL(SUM(good_qty),0) FROM mes_work_report r WHERE r.order_id w.order_id) AS report_qty FROM mes_work_order w WHERE w.status 5 -- 已完工 AND DATEDIFF(NOW(), w.close_time) 30;第二不良率统计按产品、工序统计不良率看是否超过质量控制线。SELECT p.product_code, r.process_id, SUM(r.bad_qty) / (SUM(r.good_qty) SUM(r.bad_qty)) AS bad_rate FROM mes_work_report r JOIN mes_work_order w ON r.order_id w.order_id JOIN mes_product p ON w.product_id p.product_id GROUP BY p.product_code, r.process_id HAVING bad_rate 0.05;第三设备稼动率用报工的可计算工时和理论工时对比。SELECT line_id, SUM(good_qty) * 0.5 AS actual_work_hours, -- 0.5为单件标准工时 COUNT(DISTINCT ws_id) * 8 AS planned_hours -- 8为每班次小时数 FROM mes_work_report WHERE report_time DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY line_id;这三条SQL都很实用但前提是报工数据字段完整、唯一键可靠。如果第一张表对不上多数问题出在报工漏报或重复报第二张表异常要查不良原因字典是否规范第三张表不准要检查标准工时维护是否正确。我后来养成了一个习惯每次MES项目上线第一周每天跑一遍这三条SQL看趋势有异常就顺着报工事务日志倒查。这个习惯帮我提前发现了不少“看起来能跑、实际数据是脏”的隐患。从那以后我每次报工相关变更都强制走一遍“唯一键状态机对账SQL”三件套数据库里再也没出现过对不上的糊涂账。希望这份PDF拆解和动手思路能帮到你真正让MES系统成为车间里的“明白账”而不是第二个Excel。本文还有配套的精品资源点击获取