基于若依框架的轻量级MES落地实践：PLC、扫码与质量闭环

简介：本资源是一份面向制造业数字化转型从业者、MES系统实施工程师及工业信息化学习者的专业入门文档，系统讲解智能制造核心系统——制造执行系统（MES）的定位、功能架构与落地价值。文档以清晰逻辑展开：先阐明MES在ERP与设备层之间的承上启下作用，再分模块详解其在生产管控、质量追溯、设备稼动分析、异常报警、智能仓储及物料防呆等关键场景中的具体实现；同时呈现MES与PLM、WMS、EAP等系统的集成关系，并附有典型系统架构图、功能模块清单与平台技术特性（如模块化设计、触控适配、ClickOnce自动更新）。资源为单个PDF文件，大小2.83MB，内容结构完整、图文结合，适合快速建立MES知识框架或作为项目方案参考依据。目前已有495人学习下载，是理解MES本质与企业级应用路径的高实用性入门材料。

1. MES不是ERP的简化版：它专治车间里“人喊人、表传表、错漏堆成山”的实时失控

你刚接手一个汽配厂的数字化改造项目，产线主管拍着桌子说：“系统里显示A工位已完成100件，可现场箱子还是空的！”——这不是数据延迟，是MES（制造执行系统）没真正跑起来。MES不是ERP的车间插件，也不是把Excel搬上网页就叫智能制造；它是连接计划层与设备层的实时神经中枢，核心任务只有一个：在秒级粒度下，让“计划下达→工单派发→工序报工→质量判定→物料追溯”这条链路全程可视、可溯、可纠。标题里的《智能制造系统MES简介.pdf》这类文档，常被误读为概念扫盲材料，实则应是落地前的“作战地图”：它必须明确回答——你的产线有没有设备联网基础？工艺BOM是否结构化到工序级？质检标准能否拆解为可采集的字段？工人操作习惯是否支持扫码/RFID？我见过太多项目卡在“PDF读完了，系统却动不了”：因为没把PDF里每一页的定义，对应到车间里一台PLC的寄存器地址、一个扫码枪的触发逻辑、一个质检员手指点触的UI按钮。本文不讲抽象架构图，只拆解一个真实能跑通的MES最小闭环：从若依框架二次开发起步，用3个接口打通PLC、扫码枪和数据库，让第一张工单在5分钟内完成“派发-开工-报工-入库”全流程。适合产线有基础自动化、IT人员能写Java/SQL、且拒绝PPT式交付的工程师。

2. 为什么选若依框架做MES底座：不是因为它开源，而是它把“车间脏活”封装成了可配置模块

若依（RuoYi）框架在制造业MES落地中突然走热，并非偶然。当企业需要快速验证MES价值，又不愿被传统厂商绑定数年时，基于若依二次开发成为高性价比选择。但必须清醒：若依本身不是MES，它只是提供了一套可裁剪的权限引擎、流程引擎和低代码表单能力。真正决定成败的，是它如何承接车间特有的“脏数据”和“糙流程”。

2.1 车间场景倒逼出的若依适配改造点

传统若依默认的“用户-角色-菜单”权限模型，在车间完全失效。工人不需登录后台，只需扫码触发工单；班组长要看到本班组所有机台实时状态，而非按部门树形展开。我们做的第一项改造，是重写SysUserMapper.xml中的查询逻辑：

<!-- 改造前：按部门ID查用户 --> <select id="selectUserList" resultType="SysUser"> SELECT * FROM sys_user WHERE dept_id = #{deptId} </select> <!-- 改造后：按产线+岗位查用户（支持扫码自动匹配） --> <select id="selectUserByLineAndPost" resultType="SysUser"> SELECT u.* FROM sys_user u INNER JOIN sys_user_post up ON u.user_id = up.user_id INNER JOIN sys_post p ON up.post_id = p.post_id WHERE p.post_code = #{postCode} AND u.line_code = #{lineCode} </select>

提示：line_code和post_code字段需在sys_user表中新增，这是车间权限隔离的物理基础。post_code对应“焊工”“装配工”等岗位编码，line_code对应“L101”“L202”等产线编码。这样扫码时，系统根据二维码中的产线号+岗位码，直接拉取该岗位当前可用人员，避免工人误扫其他产线工单。

2.2 工单状态机：用若依的流程引擎模拟车间真实流转

MES工单绝非简单的“待开始→进行中→已完成”。它必须反映车间物理约束：

• 某工序需前道质检合格才能开工（状态依赖）
• 某设备故障时，关联工单自动挂起（外部事件触发）
• 换模时间超30分钟，系统强制生成停机记录（时间阈值）

若依自带的Activiti流程引擎在此处成为关键。我们定义工单主状态为status（1=待派发,2=已派发,3=进行中,4=暂停,5=完成），但通过process_instance_id关联Activiti流程实例，将复杂规则下沉：

// 在工单服务类中监听扫码开工事件 public void onScanStart(Long workOrderId) { WorkOrder order = workOrderMapper.selectById(workOrderId); // 检查前道质检是否通过（跨表强校验） QualityRecord lastQc = qualityRecordMapper.selectLastByMaterial(order.getMaterialNo()); if (!"PASS".equals(lastQc.getResult())) { throw new ServiceException("前道质检未通过，禁止开工"); } // 启动Activiti流程实例，触发设备占用检查 runtimeService.startProcessInstanceByKey("workOrderProcess", Collections.singletonMap("workOrderId", workOrderId)); }

参数说明：workOrderProcess是预定义的BPMN流程图ID，其中包含“设备占用校验”服务任务节点。该节点调用PLC通信模块，实时读取目标设备machine_status寄存器值，若为BUSY则抛出异常并回滚流程。这比单纯数据库字段校验更可靠——因为设备真实状态可能未同步到数据库。

2.3 把若依的“表单设计”变成车间数据采集器

若依的低代码表单功能，在MES中价值被严重低估。它不是用来建HR档案，而是把质检标准、工艺参数、设备点检项，全部转化为可配置的动态表单。例如，某焊接工序要求录入：电流（数值）、电压（数值）、焊缝长度（数值）、目视缺陷（多选框：气孔/裂纹/未熔合）。我们在若依表单设计器中创建welding_form，字段类型严格对应：

表单提交后，后端自动将current值写入PLC指定地址，并将defect选项拼接为字符串存入quality_record.defect_desc字段。关键点在于：表单ID（welding_form）与工序编码（OP-001）绑定，扫码进入工单时，系统自动加载对应表单——工人永远只看到自己该填的内容，杜绝误操作。

3. 用3个真实接口打通MES“数据断点”：PLC读写、扫码触发、质量判定

MES落地最大的幻觉，是以为部署完系统就自动产生数据。现实是：90%的失败源于接口没对齐。以下三个接口，是我们验证过最易复现、也最常翻车的“数据咽喉”。

3.1 PLC通信接口：别碰S7协议，用OPC UA统一收口

很多团队一上来就啃西门子S7协议，结果卡在防火墙穿透、CPU负载飙升、数据丢包上。我们的血泪经验：所有PLC通信必须经OPC UA服务器中转。以Kepware为例，配置步骤极简：

1. 在Kepware中新建通道，选择对应PLC型号（如SIMATIC S7-1200）
2. 添加设备，填写PLC IP和机架/槽号
3. 创建标签组，将关键寄存器映射为OPC UA节点（如ns=2;s=MachineStatus）
4. 若依后端通过eclipse-milo客户端读取：

// Maven引入 <dependency> <groupId>org.eclipse.milo</groupId> <artifactId>sdk-client</artifactId> <version>0.6.8</version> </dependency>

// Java读取PLC状态 OpcUaClient client = OpcUaClient.create(endpointUrl); client.connect().get(); DataValue value = client.readValue(0, TimestampsToReturn.Both, new NodeId(2, "MachineStatus")).get(); String status = value.getValue().getValue().toString(); // 返回"RUNNING"或"STOPPED"

避坑重点：

• Kepware的OPC UA端口默认为53530，需在PLC防火墙放行该端口，而非S7协议的102端口
• readValue方法第二个参数0代表毫秒级时间戳精度，车间数据无需纳秒级，设为0降低PLC负载
• 若PLC返回null，先检查Kepware日志中是否报“BadNotConnected”，常见于PLC未启用OPC UA服务器功能（需在TIA Portal中勾选“Enable OPC UA Server”）

3.2 扫码枪集成：用HTTP Webhook替代串口监听

老方案用Java串口库监听COM口，稳定性差、调试难。新方案让扫码枪工作在USB HID键盘模式，扫码内容直接输入焦点文本框，再由前端触发Webhook：

// 前端监听扫码（假设扫码内容为工单号+工序码，如"W123456-OP001"） document.getElementById('scanInput').addEventListener('input', function(e) { const code = e.target.value.trim(); if (/^W\d{6}-OP\d{3}$/.test(code)) { // 触发工单开工 fetch('/api/workorder/start', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({scanCode: code}) }).then(res => res.json()).then(data => { if (data.code === 200) { alert('工单已启动！请开始作业'); e.target.value = ''; // 清空输入框 } }); } });

参数说明：扫码枪需设置为HID模式（具体方法见厂商手册），并配置前缀符（如W）和分隔符（如-），确保前端正则能精准识别。此方案规避了串口驱动兼容性问题，且扫码响应速度<100ms。

3.3 质量判定接口：用“双因子校验”堵住人为放行漏洞

质检员常因赶产量，手动点击“合格”跳过检测。我们的解决方案是：质量判定必须同时满足硬件信号+人工确认。例如，某尺寸检测工位：

• 光电传感器检测零件到位（PLC寄存器DB20.DBX0.0为1）
• 三坐标测量仪上传数据（通过FTP或MQTT）
• 质检员在若依界面点击“确认合格”

后端校验逻辑：

public boolean validateQuality(String workOrderId) { // 1. 检查PLC传感器信号 boolean sensorOk = plcService.readBool("DB20.DBX0.0"); if (!sensorOk) return false; // 2. 检查测量数据是否已上传（查FTP目录或MQTT消息队列） String ftpPath = "/quality/" + workOrderId + ".csv"; if (!ftpClient.exists(ftpPath)) return false; // 3. 检查人工确认状态（数据库字段） WorkOrder order = workOrderMapper.selectById(workOrderId); return "CONFIRMED".equals(order.getQualityStatus()); }

避坑重点：

• PLC传感器信号必须用上升沿触发（即仅在零件首次到位时为true），避免重复判定
• FTP文件存在性检查需加超时（如30秒），防止网络抖动导致误判
• 人工确认按钮需绑定防抖（debounce 500ms），杜绝双击误操作

4. MES落地必踩的5个坑：不是技术不行，是没看清车间的“物理约束”

MES不是纯软件工程，它是物理世界与数字世界的契约。以下坑点，90%的失败项目都栽在同一块石头上。

4.1 现象：工单状态显示“已完成”，但仓库实际没收到货

原因：系统将“工序报工完成”等同于“入库完成”，忽略了车间物流环节（如AGV运输、人工搬运）的时间差。
解决：在MES中增设“物流状态”字段，与WMS系统对接。当AGV到达指定货架，其RFID读写器触发/api/logistics/arrive接口，才更新库存。若无WMS，则用扫码枪二次确认——工人在货架旁扫码，系统比对工单号与货架号，一致才解锁入库。

4.2 现象：同一工单在不同终端显示不同状态（PC端显示进行中，平板端显示已暂停）

原因：前端状态缓存未同步，且未采用WebSocket推送。工人在平板端暂停工单，PC端仍显示旧状态。
解决：所有状态变更操作，后端必须触发WebSocket广播：

// Spring Boot中配置WebSocket @MessageMapping("/workorder/status") @SendTo("/topic/workorder") public WorkOrderStatus updateStatus(@Payload WorkOrderStatus status) { workOrderMapper.updateStatus(status); return status; // 广播给所有订阅者 }

前端订阅：stompClient.subscribe('/topic/workorder', callback)。注意：WebSocket连接需心跳保活（ping/pong间隔≤30秒），否则车间WiFi环境易断连。

4.3 现象：扫码报工时提示“工单不存在”，但数据库明明有记录

原因：扫码内容含不可见字符（如Windows换行符\r\n），或二维码生成时编码格式错误（ISO-8859-1 vs UTF-8）。
解决：在扫码接收接口首行强制清洗：

@PostMapping("/start") public Result start(@RequestBody String scanCode) { String cleanCode = scanCode.trim().replaceAll("[\\r\\n\\u200B]", ""); // 清除回车、换行、零宽空格 // 后续逻辑... }

4.4 现象：PLC数据每5秒刷新一次，但MES页面显示“最后更新：2分钟前”

原因：前端轮询间隔（如30秒）远大于数据采集频率，且未处理网络请求失败时的本地缓存。
解决：改用Server-Sent Events（SSE）实现服务端主动推送：

@GetMapping(value = "/plc-data", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public SseEmitter getPlcData() { SseEmitter emitter = new SseEmitter(30000L); // 超时30秒 plcDataService.startPush(emitter); // 启动推送线程 return emitter; }

前端用EventSource接收，天然支持断线重连。

4.5 现象：若依后台导出Excel的工单列表，与车间看板数据不一致

原因：导出功能直接查数据库快照，而看板数据来自Redis缓存（含实时PLC状态）。两者数据源不一致。
解决：导出前强制同步缓存到DB：

// 导出前调用 plcCacheService.syncToDatabase(); // 将Redis中最新PLC状态批量写入DB // 再执行原导出逻辑

提示：此操作会增加导出耗时，需在导出按钮添加loading状态，并提示“正在同步实时数据，请稍候”。

5. 让MES真正“活”起来的3个进阶技巧：从报表工具升级为决策引擎

MES的价值峰值，不在上线那一刻，而在它开始主动干预生产节奏时。以下是我在多个产线验证过的、无需大改架构就能落地的技巧。

5.1 用“工序节拍预测”替代静态工时设定

传统MES为每道工序设定固定标准工时（如焊接：120秒），但实际受材料批次、环境温湿度、工人熟练度影响极大。我们改用滚动窗口动态预测：

• 每完成10件，计算最近10次的实际节拍均值与标准差
• 若当前节拍 > 均值+2σ，系统自动弹窗提醒班组长：“OP-001工序节拍异常，建议检查焊枪参数”
• 同时将异常数据标记为is_anomaly=1，供后续AI模型训练

实现代码（在报工成功后触发）：

// 报工完成后，更新工序节拍统计 public void updateCycleTime(String operationCode, Long actualTimeMs) { // 查询最近10条记录 List<CycleTimeRecord> recent = cycleTimeMapper.selectRecent(operationCode, 10); double avg = recent.stream().mapToLong(CycleTimeRecord::getTimeMs).average().orElse(0); double std = Math.sqrt(recent.stream() .mapToLong(CycleTimeRecord::getTimeMs) .map(d -> Math.pow(d - avg, 2)) .average().orElse(0)); // 判断是否异常 boolean isAnomaly = actualTimeMs > avg + 2 * std; if (isAnomaly) { // 发送企业微信告警 wecomService.sendAlert("工序异常", String.format("工序%s节拍超限：%dms（均值%dms）", operationCode, actualTimeMs, (long)avg)); } }

参数说明：actualTimeMs为扫码开工到扫码完工的时间戳差值，单位毫秒。滚动窗口设为10件是平衡灵敏度与稳定性——太少易误报，太多响应滞后。

5.2 把质检数据反哺工艺参数：构建“检测-调整”闭环

某注塑车间长期困扰于产品毛刺率高。我们发现：当模具温度传感器读数<120℃时，毛刺率飙升。于是将质检结果与PLC参数联动：

后端定时任务（每15分钟执行）：

@Scheduled(fixedRate = 900000) // 15分钟 public void autoAdjustProcess() { // 查询最近1小时毛刺率超标工单 List<WorkOrder> highBurrOrders = workOrderMapper.selectHighBurrOrders(60); if (!highBurrOrders.isEmpty()) { // 读取当前模具温度 double temp = plcService.readDouble("DB30.DBD8"); if (temp < 120.0) { // 写入新温度 plcService.writeDouble("DB30.DBD8", 125.0); log.info("自动提升模具温度至125℃"); } } }

注意：此功能必须加人工确认开关。首次启用时，系统弹窗：“检测到毛刺率异常，建议提升模具温度至125℃，是否执行？”——既保证安全，又培养工人信任感。

5.3 用“数字孪生看板”替代静态报表：让产线状态一眼可知

不要做复杂的3D建模，用轻量级SVG+实时数据即可。例如，产线看板核心区域：

<!-- SVG产线拓扑图 --> <svg width="1200" height="300"> <!-- 设备1：绿色=运行，红色=故障 --> <rect x="50" y="50" width="100" height="60" fill="${device1.status == 'RUNNING' ? 'green' : 'red'}" /> <text x="60" y="85">L101-01</text> <!-- 实时节拍进度条 --> <rect x="200" y="60" width="${progressWidth}" height="20" fill="blue"/> <text x="205" y="75">${progressPercent}%</text> </svg>

后端提供/api/line-status接口，返回JSON：

{ "devices": [ {"id": "L101-01", "status": "RUNNING", "load": 85}, {"id": "L101-02", "status": "ALARM", "load": 100} ], "progress": {"width": 65, "percent": 65} }

前端用setInterval每5秒拉取，配合CSS过渡动画，让进度条平滑增长。关键价值在于：班组长不用点开层层菜单，抬头看大屏就知道哪台设备卡住了、整体进度是否落后。

我带过的每个MES项目，最终都回归到一个朴素事实：系统好不好，不看PPT上的架构图有多炫，而看夜班工人凌晨三点扫码报工时，手指会不会犹豫半秒。那些被反复打磨的扫码逻辑、被压测到崩溃边缘的PLC通信、被工人骂了三次才改对的质检表单——才是MES真正的骨骼。希望帮到你。

本文还有配套的精品资源，点击获取