简介这份PDF资料聚焦智能制造与MES制造执行系统应用面向制造业信息化从业者、智能工厂规划人员及企业IT管理者帮助理解智能制造的内涵、MES在车间层承上启下的枢纽作用以及MES与ERP、底层自动化设备、物联网、工业大数据等系统的集成关系。资源为1个PDF文件压缩包约2.68MB内容源自e-works数字企业网总编黄培博士的专题分享系统梳理了智能制造的技术融合路径、MES需解决的现场透明化与生产追溯等核心问题、国内外MES供应商格局及智能制造市场热点观察。读者可从中获取MES选型实施要点、纵向集成与数字化映射等应用趋势以及e-works在智能制造咨询、国际考察方面的实践经验适合作为企业推进智能制造与MES规划的参考材料。目前已有159人学习。1. 智能制造与MES应用从一份PDF标题拆出可落地的车间数字化方案车间里最常听到的一句话是“系统里显示做完了但仓库没收到货”。这不是段子是很多工厂上MES之前的状态ERP管订单PLC管设备Excel管排产三套数据各说各话。智能制造与MES应用.pdf 这个标题核心不是“智能制造”四个字有多大而是MES制造执行系统作为中间层怎么把计划层的工单拆成工位能执行的指令再把设备与人员的实绩回传上去。它适合两类人一类是工厂IT或工艺工程师正被要求“上个MES”另一类是软件开发者想用若依框架这类快速开发底座搭一套MES案例。下面按“先搞清楚MES到底管什么、再动手搭最小闭环、最后避坑”的顺序展开中间会给出可复现的配置与代码片段。2. MES在智能制造里的真实定位别把它当成大号ERP2.1 计划层、执行层、设备层各自的数据边界很多项目翻车是因为把MES当成了ERP的子系统。ERP关心的是“什么时候交货、成本多少”MES关心的是“现在这条线在做什么、下一件做什么、良率多少”。常见做法是ERP把工单下发给MESMES按产线产能拆成工序级任务再通过OPC UA或Modbus把参数下到设备同时从设备采集状态与产量。设备层不直接连ERP执行层也不直接改订单交期。边界一旦模糊就会出现“ERP改个数量MES里工单对不上”的玄学问题。2.2 一个工单从下发到完工的完整状态流转以离散制造为例工单状态通常经历已下发→已排产→生产中→待检验→已完工→已入库。每个状态变更都要落库并带时间戳否则追溯时只能靠回忆。下面是一个简化的状态机表用SQL建表就能跑。-- MES工单主表记录工单全生命周期状态 CREATE TABLE mes_work_order ( wo_id VARCHAR(32) PRIMARY KEY, -- 工单号与ERP一致 product_code VARCHAR(64) NOT NULL, -- 产品编码 plan_qty INT NOT NULL, -- 计划数量 done_qty INT DEFAULT 0, -- 已完成数量 status TINYINT DEFAULT 0, -- 0已下发 1已排产 2生产中 3待检验 4已完工 5已入库 line_code VARCHAR(32), -- 产线编号 plan_start DATETIME, -- 计划开工 plan_end DATETIME, -- 计划完工 actual_start DATETIME, -- 实际开工 actual_end DATETIME, -- 实际完工 create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );逻辑说明status用TINYINT而不是字符串是为了后续做状态机校验时比较高效done_qty单独存而不是每次sum报工记录是为了看板查询快。参数上wo_id必须与ERP工单号一致否则对账时会出现“两张皮”。plan_qty和done_qty都设NOT NULL避免空值导致看板计算报错。2.3 为什么很多MES项目先做报工和追溯而不是先做排产排产算法依赖工艺路线、设备产能、换型时间等基础数据这些数据在多数工厂里并不完整。而报工和追溯只需要工位扫码或点按钮数据立刻能闭环工人也能看到“我干了多少、良率多少”。先上这两个模块三个月内能出可见效果再推排产阻力小得多。这也是mes案例里最常见的落地顺序。3. 用若依框架搭MES最小闭环工单、报工、看板三张表跑通3.1 若依框架选型理由与MES模块划分若依RuoYi是一套基于Spring Boot和Vue的后台管理快速开发框架自带用户、角色、菜单、部门、数据权限。MES需要的工单管理、报工记录、看板查询本质上都是增删改查加权限控制用若依能省掉登录鉴权和菜单配置的重复劳动。常见做法是把MES拆成四个模块基础数据产品、产线、工序、工单管理、生产报工、看板报表。每个模块对应若依的一个菜单目录数据权限按产线隔离。3.2 报工接口的代码实现与事务边界报工是MES里并发最高的操作一个工位一天可能扫几百次。下面是一个基于若依代码风格的Service方法核心是“插入报工记录”和“更新工单完成数量”必须在同一个事务里。Service public class MesReportServiceImpl implements IMesReportService { Autowired private MesReportMapper reportMapper; Autowired private MesWorkOrderMapper workOrderMapper; /** * 工位报工合格数累加不合格数单独记录 * param report 报工参数含工单号、工位、合格数、不合格数 * return 更新后的工单完成数量 */ Override Transactional(rollbackFor Exception.class) public int submitReport(MesReport report) { // 1. 校验工单状态必须是“生产中” MesWorkOrder wo workOrderMapper.selectById(report.getWoId()); if (wo null || wo.getStatus() ! 2) { throw new ServiceException(工单不存在或不在生产中状态); } // 2. 插入报工明细 report.setReportTime(new Date()); reportMapper.insert(report); // 3. 累加合格数量用SQL原子更新避免并发覆盖 int rows workOrderMapper.addDoneQty(report.getWoId(), report.getOkQty()); if (rows 0) { throw new ServiceException(工单完成数量更新失败); } return wo.getDoneQty() report.getOkQty(); } }逻辑说明先查工单状态再插入是为了防止对已完工工单重复报工。addDoneQty对应的SQL是UPDATE mes_work_order SET done_qty done_qty #{qty} WHERE wo_id #{woId}用数据库行锁保证并发安全而不是在Java里先读再写。参数上okQty和ngQty分开传ngQty不参与done_qty累加但会进入不良品统计。事务注解必须加rollbackFor否则受检异常不会回滚。3.3 看板查询的SQL与索引设计看板要展示“今日各产线产量、良率、在制工单数”。如果每次都用SELECT SUM(ok_qty) FROM mes_report WHERE DATE(report_time)CURDATE()数据量到百万级就会拖慢。常见做法是建一张按天汇总的中间表或者给report_time加索引并避免在字段上使用函数。-- 给报工表加联合索引覆盖产线和时间查询 ALTER TABLE mes_report ADD INDEX idx_line_time (line_code, report_time); -- 看板查询今日各产线合格数与不良数 SELECT r.line_code, SUM(r.ok_qty) AS ok_total, SUM(r.ng_qty) AS ng_total, ROUND(SUM(r.ok_qty) / (SUM(r.ok_qty) SUM(r.ng_qty)) * 100, 2) AS yield_rate FROM mes_report r WHERE r.report_time CURDATE() AND r.report_time CURDATE() INTERVAL 1 DAY GROUP BY r.line_code;逻辑说明用 CURDATE() AND CURDATE()1代替DATE(report_time)CURDATE()是为了让索引生效。idx_line_time的顺序是line_code在前、report_time在后因为看板通常先按产线过滤再按时间过滤。如果查询条件只有时间没有产线这个索引就用不上需要再建一个单独的时间索引。良率计算里分母为0的情况要在应用层处理SQL里加NULLIF也可以。4. 避坑与排查MES上线后最容易被叫去救火的五件事4.1 报工数量与ERP入库数量对不上现象MES看板显示完工100件ERP入库只有95件。原因MES的done_qty在报工时累加但检验环节发现5件不合格需要返工返工后没有回冲工单数量。解决在检验节点增加“不合格回冲”逻辑把ng_qty从done_qty里扣减或者约定done_qty只统计合格品检验不合格时单独走返工工单。血泪经验是报工和检验的职责必须在需求阶段就写清楚不能等上线后靠对账脚本补。4.2 工位扫码后页面卡住刷新才显示成功现象工人扫码报工点击提交后按钮转圈实际数据已写入但页面没跳转。原因报工接口里同步调用了看板刷新或消息推送第三方服务超时导致响应慢。解决把非核心逻辑改成异步用Spring的Async或消息队列解耦。参数上报工接口的响应时间应控制在500毫秒以内超过1秒工人就会重复点击。注意异步方法不能和事务方法写在同一个类里否则代理不生效。4.3 若依框架下数据权限配错A产线看到B产线工单现象产线组长登录后能看到其他产线的在制工单。原因若依的数据权限默认按部门过滤但MES里产线和部门不是一一对应或者角色配了“全部数据权限”。解决在工单和报工表的Mapper查询里手动拼line_code IN (当前用户产线)不要依赖框架的自动过滤。常见做法是建一张用户-产线关联表登录时把产线列表放进Redis查询时从缓存取。4.4 设备采集频率过高导致数据库写入瓶颈现象MES运行一周后报工和状态表写入变慢磁盘IO跑满。原因OPC UA采集程序每100毫秒写一次设备状态一天产生86万条记录。解决设备状态变化才写库或者先写时序数据库如InfluxDB再定时汇总到MySQL。参数上离散制造的状态采集间隔建议不低于1秒流程行业可以放宽到5秒。如果必须高频采集至少把历史数据和业务数据分库。4.5 工单状态回退没有后悔药现象工人误点“完工”实际还有20件没做但系统不允许改回“生产中”。原因状态机只写了正向流转没有设计回退路径。解决在状态变更接口里增加“反审核”操作但必须记录操作人和原因并限制只有班组长以上角色可执行。注意回退时要同步扣减done_qty否则数量会虚高。这个坑在mes系统验收阶段几乎必现提前留好回退按钮比事后改数据库强。5. 从单点报工到车间级追溯一个可验证的进阶技巧当工单、报工、看板跑通之后下一步通常是做批次追溯。追溯的核心不是记录“谁做的”而是记录“哪一批物料、在哪台设备、用哪套参数、做成了哪个成品”。一个低成本验证方法是在报工记录里增加物料批次号和设备编号两个字段然后写一个递归查询从成品工单反查所有关联的报工记录和物料批次。-- 追溯查询给定成品工单号查出所有报工记录及物料批次 SELECT r.wo_id, r.line_code, r.station_code, r.equipment_code, r.material_batch, r.ok_qty, r.report_time FROM mes_report r WHERE r.wo_id WO20250101001 ORDER BY r.report_time;逻辑说明material_batch在报工时由扫码枪录入equipment_code从设备采集程序自动带出。如果要做双向追溯从物料批次反查流向再建一个material_batch到wo_id的索引即可。参数上批次号建议统一长度和编码规则否则后期做模糊查询会全表扫描。我自己的习惯是每上一个新模块先拿一周的真实数据跑一遍追溯查询看能不能在30秒内从成品查到原料。如果查不出来不是SQL问题是报工时字段没填全。MES的追溯能力不取决于算法多复杂取决于最基础的那几次扫码有没有被强制执行。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/30 16:44:30 · 阅读 1.2k 智能制造与MES应用：基于若依框架的车间数字化落地案例
简介这份PDF资料聚焦智能制造与MES制造执行系统应用面向制造业信息化从业者、智能工厂规划人员及企业IT管理者帮助理解智能制造的内涵、MES在车间层承上启下的枢纽作用以及MES与ERP、底层自动化设备、物联网、工业大数据等系统的集成关系。资源为1个PDF文件压缩包约2.68MB内容源自e-works数字企业网总编黄培博士的专题分享系统梳理了智能制造的技术融合路径、MES需解决的现场透明化与生产追溯等核心问题、国内外MES供应商格局及智能制造市场热点观察。读者可从中获取MES选型实施要点、纵向集成与数字化映射等应用趋势以及e-works在智能制造咨询、国际考察方面的实践经验适合作为企业推进智能制造与MES规划的参考材料。目前已有159人学习。1. 智能制造与MES应用从一份PDF标题拆出可落地的车间数字化方案车间里最常听到的一句话是“系统里显示做完了但仓库没收到货”。这不是段子是很多工厂上MES之前的状态ERP管订单PLC管设备Excel管排产三套数据各说各话。智能制造与MES应用.pdf 这个标题核心不是“智能制造”四个字有多大而是MES制造执行系统作为中间层怎么把计划层的工单拆成工位能执行的指令再把设备与人员的实绩回传上去。它适合两类人一类是工厂IT或工艺工程师正被要求“上个MES”另一类是软件开发者想用若依框架这类快速开发底座搭一套MES案例。下面按“先搞清楚MES到底管什么、再动手搭最小闭环、最后避坑”的顺序展开中间会给出可复现的配置与代码片段。2. MES在智能制造里的真实定位别把它当成大号ERP2.1 计划层、执行层、设备层各自的数据边界很多项目翻车是因为把MES当成了ERP的子系统。ERP关心的是“什么时候交货、成本多少”MES关心的是“现在这条线在做什么、下一件做什么、良率多少”。常见做法是ERP把工单下发给MESMES按产线产能拆成工序级任务再通过OPC UA或Modbus把参数下到设备同时从设备采集状态与产量。设备层不直接连ERP执行层也不直接改订单交期。边界一旦模糊就会出现“ERP改个数量MES里工单对不上”的玄学问题。2.2 一个工单从下发到完工的完整状态流转以离散制造为例工单状态通常经历已下发→已排产→生产中→待检验→已完工→已入库。每个状态变更都要落库并带时间戳否则追溯时只能靠回忆。下面是一个简化的状态机表用SQL建表就能跑。-- MES工单主表记录工单全生命周期状态 CREATE TABLE mes_work_order ( wo_id VARCHAR(32) PRIMARY KEY, -- 工单号与ERP一致 product_code VARCHAR(64) NOT NULL, -- 产品编码 plan_qty INT NOT NULL, -- 计划数量 done_qty INT DEFAULT 0, -- 已完成数量 status TINYINT DEFAULT 0, -- 0已下发 1已排产 2生产中 3待检验 4已完工 5已入库 line_code VARCHAR(32), -- 产线编号 plan_start DATETIME, -- 计划开工 plan_end DATETIME, -- 计划完工 actual_start DATETIME, -- 实际开工 actual_end DATETIME, -- 实际完工 create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );逻辑说明status用TINYINT而不是字符串是为了后续做状态机校验时比较高效done_qty单独存而不是每次sum报工记录是为了看板查询快。参数上wo_id必须与ERP工单号一致否则对账时会出现“两张皮”。plan_qty和done_qty都设NOT NULL避免空值导致看板计算报错。2.3 为什么很多MES项目先做报工和追溯而不是先做排产排产算法依赖工艺路线、设备产能、换型时间等基础数据这些数据在多数工厂里并不完整。而报工和追溯只需要工位扫码或点按钮数据立刻能闭环工人也能看到“我干了多少、良率多少”。先上这两个模块三个月内能出可见效果再推排产阻力小得多。这也是mes案例里最常见的落地顺序。3. 用若依框架搭MES最小闭环工单、报工、看板三张表跑通3.1 若依框架选型理由与MES模块划分若依RuoYi是一套基于Spring Boot和Vue的后台管理快速开发框架自带用户、角色、菜单、部门、数据权限。MES需要的工单管理、报工记录、看板查询本质上都是增删改查加权限控制用若依能省掉登录鉴权和菜单配置的重复劳动。常见做法是把MES拆成四个模块基础数据产品、产线、工序、工单管理、生产报工、看板报表。每个模块对应若依的一个菜单目录数据权限按产线隔离。3.2 报工接口的代码实现与事务边界报工是MES里并发最高的操作一个工位一天可能扫几百次。下面是一个基于若依代码风格的Service方法核心是“插入报工记录”和“更新工单完成数量”必须在同一个事务里。Service public class MesReportServiceImpl implements IMesReportService { Autowired private MesReportMapper reportMapper; Autowired private MesWorkOrderMapper workOrderMapper; /** * 工位报工合格数累加不合格数单独记录 * param report 报工参数含工单号、工位、合格数、不合格数 * return 更新后的工单完成数量 */ Override Transactional(rollbackFor Exception.class) public int submitReport(MesReport report) { // 1. 校验工单状态必须是“生产中” MesWorkOrder wo workOrderMapper.selectById(report.getWoId()); if (wo null || wo.getStatus() ! 2) { throw new ServiceException(工单不存在或不在生产中状态); } // 2. 插入报工明细 report.setReportTime(new Date()); reportMapper.insert(report); // 3. 累加合格数量用SQL原子更新避免并发覆盖 int rows workOrderMapper.addDoneQty(report.getWoId(), report.getOkQty()); if (rows 0) { throw new ServiceException(工单完成数量更新失败); } return wo.getDoneQty() report.getOkQty(); } }逻辑说明先查工单状态再插入是为了防止对已完工工单重复报工。addDoneQty对应的SQL是UPDATE mes_work_order SET done_qty done_qty #{qty} WHERE wo_id #{woId}用数据库行锁保证并发安全而不是在Java里先读再写。参数上okQty和ngQty分开传ngQty不参与done_qty累加但会进入不良品统计。事务注解必须加rollbackFor否则受检异常不会回滚。3.3 看板查询的SQL与索引设计看板要展示“今日各产线产量、良率、在制工单数”。如果每次都用SELECT SUM(ok_qty) FROM mes_report WHERE DATE(report_time)CURDATE()数据量到百万级就会拖慢。常见做法是建一张按天汇总的中间表或者给report_time加索引并避免在字段上使用函数。-- 给报工表加联合索引覆盖产线和时间查询 ALTER TABLE mes_report ADD INDEX idx_line_time (line_code, report_time); -- 看板查询今日各产线合格数与不良数 SELECT r.line_code, SUM(r.ok_qty) AS ok_total, SUM(r.ng_qty) AS ng_total, ROUND(SUM(r.ok_qty) / (SUM(r.ok_qty) SUM(r.ng_qty)) * 100, 2) AS yield_rate FROM mes_report r WHERE r.report_time CURDATE() AND r.report_time CURDATE() INTERVAL 1 DAY GROUP BY r.line_code;逻辑说明用 CURDATE() AND CURDATE()1代替DATE(report_time)CURDATE()是为了让索引生效。idx_line_time的顺序是line_code在前、report_time在后因为看板通常先按产线过滤再按时间过滤。如果查询条件只有时间没有产线这个索引就用不上需要再建一个单独的时间索引。良率计算里分母为0的情况要在应用层处理SQL里加NULLIF也可以。4. 避坑与排查MES上线后最容易被叫去救火的五件事4.1 报工数量与ERP入库数量对不上现象MES看板显示完工100件ERP入库只有95件。原因MES的done_qty在报工时累加但检验环节发现5件不合格需要返工返工后没有回冲工单数量。解决在检验节点增加“不合格回冲”逻辑把ng_qty从done_qty里扣减或者约定done_qty只统计合格品检验不合格时单独走返工工单。血泪经验是报工和检验的职责必须在需求阶段就写清楚不能等上线后靠对账脚本补。4.2 工位扫码后页面卡住刷新才显示成功现象工人扫码报工点击提交后按钮转圈实际数据已写入但页面没跳转。原因报工接口里同步调用了看板刷新或消息推送第三方服务超时导致响应慢。解决把非核心逻辑改成异步用Spring的Async或消息队列解耦。参数上报工接口的响应时间应控制在500毫秒以内超过1秒工人就会重复点击。注意异步方法不能和事务方法写在同一个类里否则代理不生效。4.3 若依框架下数据权限配错A产线看到B产线工单现象产线组长登录后能看到其他产线的在制工单。原因若依的数据权限默认按部门过滤但MES里产线和部门不是一一对应或者角色配了“全部数据权限”。解决在工单和报工表的Mapper查询里手动拼line_code IN (当前用户产线)不要依赖框架的自动过滤。常见做法是建一张用户-产线关联表登录时把产线列表放进Redis查询时从缓存取。4.4 设备采集频率过高导致数据库写入瓶颈现象MES运行一周后报工和状态表写入变慢磁盘IO跑满。原因OPC UA采集程序每100毫秒写一次设备状态一天产生86万条记录。解决设备状态变化才写库或者先写时序数据库如InfluxDB再定时汇总到MySQL。参数上离散制造的状态采集间隔建议不低于1秒流程行业可以放宽到5秒。如果必须高频采集至少把历史数据和业务数据分库。4.5 工单状态回退没有后悔药现象工人误点“完工”实际还有20件没做但系统不允许改回“生产中”。原因状态机只写了正向流转没有设计回退路径。解决在状态变更接口里增加“反审核”操作但必须记录操作人和原因并限制只有班组长以上角色可执行。注意回退时要同步扣减done_qty否则数量会虚高。这个坑在mes系统验收阶段几乎必现提前留好回退按钮比事后改数据库强。5. 从单点报工到车间级追溯一个可验证的进阶技巧当工单、报工、看板跑通之后下一步通常是做批次追溯。追溯的核心不是记录“谁做的”而是记录“哪一批物料、在哪台设备、用哪套参数、做成了哪个成品”。一个低成本验证方法是在报工记录里增加物料批次号和设备编号两个字段然后写一个递归查询从成品工单反查所有关联的报工记录和物料批次。-- 追溯查询给定成品工单号查出所有报工记录及物料批次 SELECT r.wo_id, r.line_code, r.station_code, r.equipment_code, r.material_batch, r.ok_qty, r.report_time FROM mes_report r WHERE r.wo_id WO20250101001 ORDER BY r.report_time;逻辑说明material_batch在报工时由扫码枪录入equipment_code从设备采集程序自动带出。如果要做双向追溯从物料批次反查流向再建一个material_batch到wo_id的索引即可。参数上批次号建议统一长度和编码规则否则后期做模糊查询会全表扫描。我自己的习惯是每上一个新模块先拿一周的真实数据跑一遍追溯查询看能不能在30秒内从成品查到原料。如果查不出来不是SQL问题是报工时字段没填全。MES的追溯能力不取决于算法多复杂取决于最基础的那几次扫码有没有被强制执行。希望帮到你。本文还有配套的精品资源点击获取