)
簡介一套基于.NET 4.0的SimpleMES加工裝配模擬系統(tǒng)面向MES系統(tǒng)學習者、課程設計或畢業(yè)設計人員以及需要快速搭建制造執(zhí)行原型的開發(fā)者。服務端與客戶端分工明確服務端包含基礎檔案、加工與裝配計劃管理、實時看板和數據初始化客戶端覆蓋加工、裝配及搬運過程控制和質量異常處理核心業(yè)務邏輯封裝于數據庫存儲過程便于深入研究MES的調度與數據流轉。資源包共445個文件壓縮后約10MB以175個C#源碼、36個DLL庫和12個EXE程序為主體并附帶MDF/LDF/BAK數據庫文件、DOCX設計說明書、配置文件、圖片及WAV提示音頻其中DB目錄可直接附加數據庫Doc目錄包含完整設計說明。已有557人學習下載借助這套資源不僅能獲得可運行的服務端與客戶端工程還可結合說明書理解計劃、看板、實時監(jiān)聽與異常處理之間的聯動適合作為Visual Studio 2010與SQL Server 2008 R2環(huán)境下的二次開發(fā)藍本。1. 裝配車間上MES最容易翻車的地方為什么SimpleMES能繞過去機械加工裝配類的中小車間選MES普遍卡在一個尷尬位置大廠MES實施周期長、顧問費比軟件費貴一線班組根本不買賬純靠Excel加微信群報數又永遠對不上在制數和齊套率。SimpleMES這類輕量級方案恰好把加工裝配場景里最核心的東西收成一張可維護的工單流工藝路線、多級BOM、工序報工、齊套檢查和異常處理而且它常見的技術底座是若依框架擴展方式清楚不依賴原廠顧問。這套邏輯更適合預算有限、想先用起來再迭代的數字化專員、車間主任和負責落地的IT工程師。很多人把MES想成一個大黑匣子其實加工裝配類MES的骨架一張工單流轉表就能說清楚。2. SimpleMES的數據建模核心物料、多級BOM和工藝路線怎么落到一張工單上2.1 基于若依框架的MESSimpleMES把哪些能力白送給了你若依框架在Java技術棧里普及度很高基于若依框架的MES項目一搜一大把SimpleMES是其中偏向加工裝配場景的一種開源實現。選這個底座的直接好處是用戶管理、角色權限、菜單管理、操作日志、定時任務、代碼生成器這些通用模塊齊全不用從零寫。你做MES時最費時間的是業(yè)務建模而不是用戶登錄和按鈕權限這些重復工作。RuoYi-Vue的技術棧是Spring Boot加Vue加MyBatis加MySQL招人容易二次開發(fā)門檻低。很多車間沒有專職架構師找一個能寫SSM的工程師就能維護這是我推薦它在中小廠落地的主要原因之一。再加上若依自帶定時任務和緩存監(jiān)控MES里最常用的工單超時預警、設備狀態(tài)心跳檢測都能直接掛在框架的調度器上不需要額外引一套任務系統(tǒng)。2.2 物料主數據先理清三件事編碼、單位、批次加工裝配車間的物料特點是層級多半成品要過好幾道工序才變成成品。物料主數據如果建不好后邊的BOM展開、齊套計算、報工入庫全是錯的。我一般建議在建SimpleMES的基礎數據時先把這三件事定死。第一物料編碼全局唯一禁用中文名當主鍵。第二物料類型的邊界要清楚原材料、半成品、成品三類區(qū)分開裝配場景中半成品是否要建獨立物料編碼要在項目啟動會上拍板。第三批次管理默認開啟哪怕現在的庫存量不大也要開。理由是裝配場景的追溯訴求很強一旦客戶投訴或者來料不良你要能從成品條碼倒查到批次、供應商和加工記錄沒有批次字段這個追溯鏈就斷了。物料主數據在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。類型會影響后續(xù)BOM展開時是否要繼續(xù)往下拆批次管理建議生產型和貿易型的物料都開別為了省事關掉。單位這里建議統(tǒng)一到最小計量單位裝配車間經常混用“套”和“件”如果不統(tǒng)一報工數量換算會踩坑。導入物料時常見的做法是先把Excel模板導出清洗后通過若依代碼生成器做成的導入功能批量入表。要注意Excel里如果編碼重復MySQL的唯一索引會直接拋錯數據庫層面加一道保險比什么都管用。2.3 裝配場景的關鍵配置多級BOM展開與工藝路線綁定裝配BOM的難點不是建父子關系而是變更多。今天換了一個供應商螺栓規(guī)格變了整條裝配路徑的物料需求都要跟著變。SimpleMES里通常把BOM和工藝路線分開維護工單創(chuàng)建時選擇“BOM版本加工藝路線版本”的組合再取組合后的快照數據。這樣老工單繼續(xù)走老BOM新工單自動用新版本不會互相污染。多級BOM展開的SQL在MySQL里可以靠遞歸CTE完成。加工裝配的葉子節(jié)點可能是采購件也可能自加工件但齊套計算只關心最底層物料需求所以要遞歸展開到葉子。我給一個可以直接調試的版本-- 按BOM版本遞歸展開到葉子物料并折算成根節(jié)點的用量系數 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的邏輯是先取根節(jié)點然后逐層往下子項的用量乘以父項的累計系數。bom_revision_id是BOM版本的外鍵parent_id 0表示根節(jié)點。展開后得到的unit_qty是單位成品的物料需求量后面跟工單數量相乘就得到總需求。注意遞歸CTE在MySQL 8.0以上才支持如果是5.7要么換寫法或者升級數據庫這一點會在老車間部署時經常發(fā)生提前確認版本能省不少麻煩。工藝路線相對簡單一張表就能維護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遞增編號中間要插工序時不用重排。有了這張表工單創(chuàng)建時按process_seq排序批量生成工序實例后續(xù)報工就是逐個工序走狀態(tài)邏輯就清晰了。很多MES說明書里把“工單生成的同時復制工藝路線”叫工序實例化這是SimpleMES從建模走向執(zhí)行最關鍵的一步。3. 從工單下達到完工入庫SimpleMES的工序流轉與報工邏輯3.1 一張工單在SimpleMES里怎么走完五步工序流轉是加工裝配MES的執(zhí)行主線操作工所有的操作都圍繞“當前工單當前工序”展開。常見流程分五步創(chuàng)建工單、下達車間、工序開工、報工、完工入庫。創(chuàng)建工單的時候系統(tǒng)根據產品和數量的組合自動帶出BOM版本、工藝路線版本并生成一批工序實例每道工序初始狀態(tài)是等待開工。下達車間后班組長才能看到任務并派工到產線。每道工序等待開工不等于設備正在生產真正的開工動作是操作工掃碼確認“我開始干了”這個時間點就是工時采集的起點。報工后系統(tǒng)校驗合格數、不良數同時判斷是否還有下一道工序全部工序完成后工單自動進入入庫候選狀態(tài)。這套流程的價值在于你不用額外安裝設備采集硬件也能先把工序級數據采集起來。對裝配車間來說設備自動化程度參差不齊人員動作數據比設備數據更重要。3.2 工單條碼規(guī)則怎么定從4321這個編號說起標題里的4321我理解是一套工單編號規(guī)則的典型示例。實際編碼結構可以拆成“4位產品系列 3位工藝版本 2位產線代碼 1位班次代碼”合起來就是一個可讀、可追溯的工單號。關鍵不是數字位數而是掃碼后系統(tǒng)能解析出產品、版本、產線和班次信息。生成工單號的Java代碼也可以寫得很直接public String buildWorkOrderCode(Product product, ProcessRoute route, String lineCode, Integer shiftCode) { // 4321規(guī)則示例產品系列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建議直接用廠區(qū)編號不要用產線中文名避免條形碼里出現中文導致掃碼槍亂碼。班次代碼用1、2、3對應早中晚班。這里有一個很容易忽略的坑編碼里不要加上日期日期變體天然每天不同會導致返工追溯困難。日期單獨在數據庫字段里保存掃碼查詢時傳參即可不要把動態(tài)日期拼進條碼。車間師傅掃了條碼也看不出日期反而容易掃錯工單。3.3 齊套檢查裝配車間最剛需的一張缺料清單裝配場景的典型痛點是開工前發(fā)現缺料生產已經停了才發(fā)現倉庫少一個貼片電容。齊套檢查必須在工單下達前跑一次邏輯也很直白根據工單數量和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里最容易出數據事故的地方。常見錯誤是只往報工表插入一條記錄然后不管在制數量。正確的做法是報工插入和工序數量更新必須在同一個數據庫事務里否則報工成功但工序狀態(tài)沒變在制數量就變成一筆糊涂賬。/** * 工序報工寫報工記錄并更新工序完成數量 */ Transactional(rollbackFor Exception.class) public void reportProcess(ReportDTO dto) { WorkOrderProcess wp workOrderProcessMapper.selectByIdForUpdate(dto.getProcessId()); // 狀態(tài)校驗只有運行中的工序才允許報工 if (!RUNNING.equals(wp.getStatus())) { throw new BizException(工序狀態(tài)不是運行中不能報工); } // 防錯累計合格數量不能超過工單計劃數量 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())); // 全部完成則工序狀態(tài)流轉為已完成 if (wp.getFinishedQty().compareTo(wp.getPlanQty()) 0) { wp.setStatus(FINISHED); } workOrderProcessMapper.updateById(wp); }這段代碼有三個關鍵細節(jié)。第一selectByIdForUpdate加行鎖防止兩個操作工同時掃同一道工序重復報工。第二報工數量與工序余量做校驗這一步是“防錯”裝配車間常見的錯裝漏裝問題通過數量校驗能擋住一部分。第三Transactional保證報工記錄和工序數量一起成功、一起失敗不會出現報工了但數量沒漲的情況。3.5 完工入庫與后道工序解鎖一個工單的最后一道工序報工完成后系統(tǒng)要自動把產品狀態(tài)改成待入庫同時對下道工序解除鎖定。這是通過報工后的事件觸發(fā)實現的而不是讓操作工手動去點擊“完工確認”。我見過很多項目在每一個環(huán)節(jié)都讓人去點按鈕操作工嫌煩最后直接不點數據就是死的。常見的實現方式是報工事務成功提交后通過Spring的事件發(fā)布機制監(jiān)聽工序完成事件然后自動判斷process_seq是否為該工單最大的工序如果是就更新工單狀態(tài)為完工。你要在報表上查“今日完工量”直接查這張工單狀態(tài)即可不要在Excel里再匯總一遍。4. 基于若依框架的權限配置車間里誰該看什么一個按鈕都不能多4.1 三套常用角色菜單操作工、班組長、計劃員MES上線后最讓車間反感的不是系統(tǒng)慢而是屏幕上堆滿了和自己無關的菜單。SimpleMES基于若依框架的權限體系可以很好地按角色裁剪菜單。我一般建議分三套默認角色模板。操作工只保留“我的任務、工序報工、不良上報”班組長增加“工單查詢、齊套檢查、異常處理、人員派工”計劃員增加“BOM維護、工藝路線維護、工單創(chuàng)建、庫存查詢、報表中心”。車間主任和管理層可能還要看“效率看板”但這類角色建議后置等數據穩(wěn)定了再開。在若依框架里菜單權限通過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。真正執(zhí)行時可以把role_key換成你系統(tǒng)里實際的角色標識。菜單權限的粒度建議控制到按鈕級操作工界面上連“刪除工單”的按鈕都不要出現因為越權的操作人員點錯一次整條工單數據就亂了。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項目里爭議很大的功能建議上線第一天就開啟后期再開會讓工人覺得系統(tǒng)在“突然限制自己”反而不配合。4.3 字典參數與基礎配置合格率閾值、工時版本、不良代碼若依框架的字典管理可以直接復用。MES里最典型的字典是“工序狀態(tài)”和“不良原因”。工序狀態(tài)我建議就用四個等待開工、運行中、已完成、已關閉。太多狀態(tài)會讓操作工不知道選哪個太少又無法表達返工等場景。不良原因代碼要提前跟質檢部門對齊裝配場景常見的有錯裝、漏裝、外觀劃傷、扭矩超差、尺寸超差這五類寧可先少后補也不要讓人在文本框里隨手敲中文。合格的MES說明書應該把每個字段的解釋、可選值和流轉規(guī)則寫清楚這比寫代碼重要得多。字典配置步驟很簡單在若依管理后臺的“字典管理”里新建字典類型mes_wo_status然后添加字典數據。這些數據在工單下拉框、報表篩選項里會自動生效不需要改前端代碼。5. 加工裝配場景里最常踩的5個坑按現象、原因、解決方案排查5.1 報工了但WIP在制數量對不上現象上午報工了120件下午查在制數量還是0或者變成了負數。整個車間在制數沒人敢信。原因報工表和工序狀態(tài)更新不在同一個事務里半路失敗導致報工記錄寫進去了但工序數量沒更新更常見的是直接在工單表存了一個冗余的wip_qty字段報工加一筆、入庫減一筆中間任何一步漏了就對不上。解決不要單獨存WIP字段在制數量永遠通過“累計報工數量減去累計入庫數量”實時算出來。報工、質檢判定、入庫、狀態(tài)更新全部放進一個事務。每周讓班組長抽查三個工單的在制數和現場實物進行比對堅持兩周數據可信度就上來了。5.2 齊套檢查顯示齊套開工還是缺料現象工單下達前齊套檢查通過了真正開工時倉庫發(fā)不出料。原因齊套計算用了賬面庫存而不是可用庫存。賬面庫存沒有扣掉已經預留給其他工單的數量甚至沒有扣掉已經被品質凍結的來料不良庫存。解決庫存表增加reserved_qty和frozen_qty兩個字段?？捎脦齑婵値齑?預留-凍結。同時把齊套檢查從“即時查詢”改成“工單下達時生成快照”缺少的物料鎖定需求后續(xù)采購到貨后自動釋放預留。操作上倉庫每次做庫存異動時都要在系統(tǒng)里同步更新預留量這一步做不到齊套檢查永遠不準。5.3 掃碼槍輸入項目標題時自動跳過字符現象操作工掃工單條碼輸入框里偶爾少一個字符或者最后多一個回車符導致查詢不到工單。原因掃碼槍在鍵盤仿真模式下中文輸入法會截斷字符另外掃碼槍默認的結束符是回車鍵看系統(tǒng)有沒有自動把回車轉成查詢觸發(fā)。輸入框沒有去空格和回車處理也是常見原因。解決掃碼槍配置里把工作模式設置為“鍵盤仿真回車后綴”成本低兼容性好。代碼層面對條碼做統(tǒng)一處理接收到輸入框的值先trim()掉首尾空白再去掉結尾的\r\n。查詢按鈕用回車事件觸發(fā)這樣掃碼和手動回車都能得到一致結果。不要改用USB串口模式Windows和Linux的驅動配置差異會讓你多踩三天坑。5.4 修改BOM后已下發(fā)的工單還在用舊版本但物料需求變了現象技術員改了裝配BOM結果工單報工時物料需求全是錯的要么多算要么少算。原因工單沒有對BOM做版本快照BOM修改直接影響了在制工單。解決BOM表只做新增版本不做原地修改。每個工單創(chuàng)建時把BOM明細復制到工單BOM快照表后續(xù)查詢物料需求都走快照表而不是JOIN最新BOM版本。這樣做還有一個好處就是追溯歷史工單時可以還原當時的BOM到底是什么樣。這條準則同樣適用于工藝路線工單一旦創(chuàng)建工藝版本不可變更除非顯式做工序變更單。5.5 若依定時任務和MES輪詢任務并發(fā)導致工序超時誤報現象凌晨1點一批工單被自動標記為“超時”但是實際上班次是下午4點才結束。原因若依框架自帶的定時任務默認每分鐘掃描一次而MES工序超時檢測任務也是獨立調度的兩個任務并發(fā)執(zhí)行時超時檢測讀到了還沒落庫的班次結束事件。解決為超時檢測任務補充“班次結束時間校驗”邏輯只處理當前時間大于計劃結束時間加緩沖時間的工單。在若依的調度管理里把兩個任務的執(zhí)行錯開不要都放在整點。更重要的是給定時任務加上分布式鎖避免多實例部署時重復觸發(fā)。經驗是MES里的定時任務一定要允許手動補跑否則一旦漏跑超時狀態(tài)的數據補起來會非常費勁。6. 把SimpleMES從“記錄系統(tǒng)”變成車間看板先盯住一條小時產出SQL很多MES項目死在上線三個月后沒人看報表。要避免這個結局我的建議是不要一開始就做大而全的看板而是先盯住一條小時產出SQL。對車間主任來說今天現在這一刻產線干出了多少合格件比任何漂亮圖表都管用。-- 按小時統(tǒng)計各工序的合格產出和折算標準工時 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。很多實施項目把標準工時放在工藝路線表里工單工序實例沒有復制一份結果報表只能按數量統(tǒng)計算不了效率。工序實例落庫時把標準工時快照下來是我反復強調的一個點。報表穩(wěn)定后可以算極簡版OEE?？趶讲恍枰非蠛徒炭茣恢履苡镁托泻细癞a出數量乘以標準工時除以設備可動工時?？蓜庸r按班次時長減去計劃停機時間。這樣算出來的OEE有一個偏差但趨勢是可靠的。對比每天的OEE波動再結合不良代碼占比就能定位是哪個工序掉鏈子。等我回頭看這些年做過的MES項目凡是能堅持三周核對小時產出數據的車間最后都把SimpleMES用成了真正管理的抓手凡是只看月報的都半途而廢了。數據這種事你不能等它自己變準要拉著班組一起較真較真兩三個禮拜大家才認賬。希望幫到你。本文還有配套的精品資源點擊獲取 裝配車間MES落地指南：SimpleMES工單流轉、BOM與齊套檢查實戰(zhàn)
簡介一套基于.NET 4.0的SimpleMES加工裝配模擬系統(tǒng)面向MES系統(tǒng)學習者、課程設計或畢業(yè)設計人員以及需要快速搭建制造執(zhí)行原型的開發(fā)者。服務端與客戶端分工明確服務端包含基礎檔案、加工與裝配計劃管理、實時看板和數據初始化客戶端覆蓋加工、裝配及搬運過程控制和質量異常處理核心業(yè)務邏輯封裝于數據庫存儲過程便于深入研究MES的調度與數據流轉。資源包共445個文件壓縮后約10MB以175個C#源碼、36個DLL庫和12個EXE程序為主體并附帶MDF/LDF/BAK數據庫文件、DOCX設計說明書、配置文件、圖片及WAV提示音頻其中DB目錄可直接附加數據庫Doc目錄包含完整設計說明。已有557人學習下載借助這套資源不僅能獲得可運行的服務端與客戶端工程還可結合說明書理解計劃、看板、實時監(jiān)聽與異常處理之間的聯動適合作為Visual Studio 2010與SQL Server 2008 R2環(huán)境下的二次開發(fā)藍本。1. 裝配車間上MES最容易翻車的地方為什么SimpleMES能繞過去機械加工裝配類的中小車間選MES普遍卡在一個尷尬位置大廠MES實施周期長、顧問費比軟件費貴一線班組根本不買賬純靠Excel加微信群報數又永遠對不上在制數和齊套率。SimpleMES這類輕量級方案恰好把加工裝配場景里最核心的東西收成一張可維護的工單流工藝路線、多級BOM、工序報工、齊套檢查和異常處理而且它常見的技術底座是若依框架擴展方式清楚不依賴原廠顧問。這套邏輯更適合預算有限、想先用起來再迭代的數字化專員、車間主任和負責落地的IT工程師。很多人把MES想成一個大黑匣子其實加工裝配類MES的骨架一張工單流轉表就能說清楚。2. SimpleMES的數據建模核心物料、多級BOM和工藝路線怎么落到一張工單上2.1 基于若依框架的MESSimpleMES把哪些能力白送給了你若依框架在Java技術棧里普及度很高基于若依框架的MES項目一搜一大把SimpleMES是其中偏向加工裝配場景的一種開源實現。選這個底座的直接好處是用戶管理、角色權限、菜單管理、操作日志、定時任務、代碼生成器這些通用模塊齊全不用從零寫。你做MES時最費時間的是業(yè)務建模而不是用戶登錄和按鈕權限這些重復工作。RuoYi-Vue的技術棧是Spring Boot加Vue加MyBatis加MySQL招人容易二次開發(fā)門檻低。很多車間沒有專職架構師找一個能寫SSM的工程師就能維護這是我推薦它在中小廠落地的主要原因之一。再加上若依自帶定時任務和緩存監(jiān)控MES里最常用的工單超時預警、設備狀態(tài)心跳檢測都能直接掛在框架的調度器上不需要額外引一套任務系統(tǒng)。2.2 物料主數據先理清三件事編碼、單位、批次加工裝配車間的物料特點是層級多半成品要過好幾道工序才變成成品。物料主數據如果建不好后邊的BOM展開、齊套計算、報工入庫全是錯的。我一般建議在建SimpleMES的基礎數據時先把這三件事定死。第一物料編碼全局唯一禁用中文名當主鍵。第二物料類型的邊界要清楚原材料、半成品、成品三類區(qū)分開裝配場景中半成品是否要建獨立物料編碼要在項目啟動會上拍板。第三批次管理默認開啟哪怕現在的庫存量不大也要開。理由是裝配場景的追溯訴求很強一旦客戶投訴或者來料不良你要能從成品條碼倒查到批次、供應商和加工記錄沒有批次字段這個追溯鏈就斷了。物料主數據在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。類型會影響后續(xù)BOM展開時是否要繼續(xù)往下拆批次管理建議生產型和貿易型的物料都開別為了省事關掉。單位這里建議統(tǒng)一到最小計量單位裝配車間經常混用“套”和“件”如果不統(tǒng)一報工數量換算會踩坑。導入物料時常見的做法是先把Excel模板導出清洗后通過若依代碼生成器做成的導入功能批量入表。要注意Excel里如果編碼重復MySQL的唯一索引會直接拋錯數據庫層面加一道保險比什么都管用。2.3 裝配場景的關鍵配置多級BOM展開與工藝路線綁定裝配BOM的難點不是建父子關系而是變更多。今天換了一個供應商螺栓規(guī)格變了整條裝配路徑的物料需求都要跟著變。SimpleMES里通常把BOM和工藝路線分開維護工單創(chuàng)建時選擇“BOM版本加工藝路線版本”的組合再取組合后的快照數據。這樣老工單繼續(xù)走老BOM新工單自動用新版本不會互相污染。多級BOM展開的SQL在MySQL里可以靠遞歸CTE完成。加工裝配的葉子節(jié)點可能是采購件也可能自加工件但齊套計算只關心最底層物料需求所以要遞歸展開到葉子。我給一個可以直接調試的版本-- 按BOM版本遞歸展開到葉子物料并折算成根節(jié)點的用量系數 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的邏輯是先取根節(jié)點然后逐層往下子項的用量乘以父項的累計系數。bom_revision_id是BOM版本的外鍵parent_id 0表示根節(jié)點。展開后得到的unit_qty是單位成品的物料需求量后面跟工單數量相乘就得到總需求。注意遞歸CTE在MySQL 8.0以上才支持如果是5.7要么換寫法或者升級數據庫這一點會在老車間部署時經常發(fā)生提前確認版本能省不少麻煩。工藝路線相對簡單一張表就能維護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遞增編號中間要插工序時不用重排。有了這張表工單創(chuàng)建時按process_seq排序批量生成工序實例后續(xù)報工就是逐個工序走狀態(tài)邏輯就清晰了。很多MES說明書里把“工單生成的同時復制工藝路線”叫工序實例化這是SimpleMES從建模走向執(zhí)行最關鍵的一步。3. 從工單下達到完工入庫SimpleMES的工序流轉與報工邏輯3.1 一張工單在SimpleMES里怎么走完五步工序流轉是加工裝配MES的執(zhí)行主線操作工所有的操作都圍繞“當前工單當前工序”展開。常見流程分五步創(chuàng)建工單、下達車間、工序開工、報工、完工入庫。創(chuàng)建工單的時候系統(tǒng)根據產品和數量的組合自動帶出BOM版本、工藝路線版本并生成一批工序實例每道工序初始狀態(tài)是等待開工。下達車間后班組長才能看到任務并派工到產線。每道工序等待開工不等于設備正在生產真正的開工動作是操作工掃碼確認“我開始干了”這個時間點就是工時采集的起點。報工后系統(tǒng)校驗合格數、不良數同時判斷是否還有下一道工序全部工序完成后工單自動進入入庫候選狀態(tài)。這套流程的價值在于你不用額外安裝設備采集硬件也能先把工序級數據采集起來。對裝配車間來說設備自動化程度參差不齊人員動作數據比設備數據更重要。3.2 工單條碼規(guī)則怎么定從4321這個編號說起標題里的4321我理解是一套工單編號規(guī)則的典型示例。實際編碼結構可以拆成“4位產品系列 3位工藝版本 2位產線代碼 1位班次代碼”合起來就是一個可讀、可追溯的工單號。關鍵不是數字位數而是掃碼后系統(tǒng)能解析出產品、版本、產線和班次信息。生成工單號的Java代碼也可以寫得很直接public String buildWorkOrderCode(Product product, ProcessRoute route, String lineCode, Integer shiftCode) { // 4321規(guī)則示例產品系列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建議直接用廠區(qū)編號不要用產線中文名避免條形碼里出現中文導致掃碼槍亂碼。班次代碼用1、2、3對應早中晚班。這里有一個很容易忽略的坑編碼里不要加上日期日期變體天然每天不同會導致返工追溯困難。日期單獨在數據庫字段里保存掃碼查詢時傳參即可不要把動態(tài)日期拼進條碼。車間師傅掃了條碼也看不出日期反而容易掃錯工單。3.3 齊套檢查裝配車間最剛需的一張缺料清單裝配場景的典型痛點是開工前發(fā)現缺料生產已經停了才發(fā)現倉庫少一個貼片電容。齊套檢查必須在工單下達前跑一次邏輯也很直白根據工單數量和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里最容易出數據事故的地方。常見錯誤是只往報工表插入一條記錄然后不管在制數量。正確的做法是報工插入和工序數量更新必須在同一個數據庫事務里否則報工成功但工序狀態(tài)沒變在制數量就變成一筆糊涂賬。/** * 工序報工寫報工記錄并更新工序完成數量 */ Transactional(rollbackFor Exception.class) public void reportProcess(ReportDTO dto) { WorkOrderProcess wp workOrderProcessMapper.selectByIdForUpdate(dto.getProcessId()); // 狀態(tài)校驗只有運行中的工序才允許報工 if (!RUNNING.equals(wp.getStatus())) { throw new BizException(工序狀態(tài)不是運行中不能報工); } // 防錯累計合格數量不能超過工單計劃數量 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())); // 全部完成則工序狀態(tài)流轉為已完成 if (wp.getFinishedQty().compareTo(wp.getPlanQty()) 0) { wp.setStatus(FINISHED); } workOrderProcessMapper.updateById(wp); }這段代碼有三個關鍵細節(jié)。第一selectByIdForUpdate加行鎖防止兩個操作工同時掃同一道工序重復報工。第二報工數量與工序余量做校驗這一步是“防錯”裝配車間常見的錯裝漏裝問題通過數量校驗能擋住一部分。第三Transactional保證報工記錄和工序數量一起成功、一起失敗不會出現報工了但數量沒漲的情況。3.5 完工入庫與后道工序解鎖一個工單的最后一道工序報工完成后系統(tǒng)要自動把產品狀態(tài)改成待入庫同時對下道工序解除鎖定。這是通過報工后的事件觸發(fā)實現的而不是讓操作工手動去點擊“完工確認”。我見過很多項目在每一個環(huán)節(jié)都讓人去點按鈕操作工嫌煩最后直接不點數據就是死的。常見的實現方式是報工事務成功提交后通過Spring的事件發(fā)布機制監(jiān)聽工序完成事件然后自動判斷process_seq是否為該工單最大的工序如果是就更新工單狀態(tài)為完工。你要在報表上查“今日完工量”直接查這張工單狀態(tài)即可不要在Excel里再匯總一遍。4. 基于若依框架的權限配置車間里誰該看什么一個按鈕都不能多4.1 三套常用角色菜單操作工、班組長、計劃員MES上線后最讓車間反感的不是系統(tǒng)慢而是屏幕上堆滿了和自己無關的菜單。SimpleMES基于若依框架的權限體系可以很好地按角色裁剪菜單。我一般建議分三套默認角色模板。操作工只保留“我的任務、工序報工、不良上報”班組長增加“工單查詢、齊套檢查、異常處理、人員派工”計劃員增加“BOM維護、工藝路線維護、工單創(chuàng)建、庫存查詢、報表中心”。車間主任和管理層可能還要看“效率看板”但這類角色建議后置等數據穩(wěn)定了再開。在若依框架里菜單權限通過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。真正執(zhí)行時可以把role_key換成你系統(tǒng)里實際的角色標識。菜單權限的粒度建議控制到按鈕級操作工界面上連“刪除工單”的按鈕都不要出現因為越權的操作人員點錯一次整條工單數據就亂了。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項目里爭議很大的功能建議上線第一天就開啟后期再開會讓工人覺得系統(tǒng)在“突然限制自己”反而不配合。4.3 字典參數與基礎配置合格率閾值、工時版本、不良代碼若依框架的字典管理可以直接復用。MES里最典型的字典是“工序狀態(tài)”和“不良原因”。工序狀態(tài)我建議就用四個等待開工、運行中、已完成、已關閉。太多狀態(tài)會讓操作工不知道選哪個太少又無法表達返工等場景。不良原因代碼要提前跟質檢部門對齊裝配場景常見的有錯裝、漏裝、外觀劃傷、扭矩超差、尺寸超差這五類寧可先少后補也不要讓人在文本框里隨手敲中文。合格的MES說明書應該把每個字段的解釋、可選值和流轉規(guī)則寫清楚這比寫代碼重要得多。字典配置步驟很簡單在若依管理后臺的“字典管理”里新建字典類型mes_wo_status然后添加字典數據。這些數據在工單下拉框、報表篩選項里會自動生效不需要改前端代碼。5. 加工裝配場景里最常踩的5個坑按現象、原因、解決方案排查5.1 報工了但WIP在制數量對不上現象上午報工了120件下午查在制數量還是0或者變成了負數。整個車間在制數沒人敢信。原因報工表和工序狀態(tài)更新不在同一個事務里半路失敗導致報工記錄寫進去了但工序數量沒更新更常見的是直接在工單表存了一個冗余的wip_qty字段報工加一筆、入庫減一筆中間任何一步漏了就對不上。解決不要單獨存WIP字段在制數量永遠通過“累計報工數量減去累計入庫數量”實時算出來。報工、質檢判定、入庫、狀態(tài)更新全部放進一個事務。每周讓班組長抽查三個工單的在制數和現場實物進行比對堅持兩周數據可信度就上來了。5.2 齊套檢查顯示齊套開工還是缺料現象工單下達前齊套檢查通過了真正開工時倉庫發(fā)不出料。原因齊套計算用了賬面庫存而不是可用庫存。賬面庫存沒有扣掉已經預留給其他工單的數量甚至沒有扣掉已經被品質凍結的來料不良庫存。解決庫存表增加reserved_qty和frozen_qty兩個字段?？捎脦齑婵値齑?預留-凍結。同時把齊套檢查從“即時查詢”改成“工單下達時生成快照”缺少的物料鎖定需求后續(xù)采購到貨后自動釋放預留。操作上倉庫每次做庫存異動時都要在系統(tǒng)里同步更新預留量這一步做不到齊套檢查永遠不準。5.3 掃碼槍輸入項目標題時自動跳過字符現象操作工掃工單條碼輸入框里偶爾少一個字符或者最后多一個回車符導致查詢不到工單。原因掃碼槍在鍵盤仿真模式下中文輸入法會截斷字符另外掃碼槍默認的結束符是回車鍵看系統(tǒng)有沒有自動把回車轉成查詢觸發(fā)。輸入框沒有去空格和回車處理也是常見原因。解決掃碼槍配置里把工作模式設置為“鍵盤仿真回車后綴”成本低兼容性好。代碼層面對條碼做統(tǒng)一處理接收到輸入框的值先trim()掉首尾空白再去掉結尾的\r\n。查詢按鈕用回車事件觸發(fā)這樣掃碼和手動回車都能得到一致結果。不要改用USB串口模式Windows和Linux的驅動配置差異會讓你多踩三天坑。5.4 修改BOM后已下發(fā)的工單還在用舊版本但物料需求變了現象技術員改了裝配BOM結果工單報工時物料需求全是錯的要么多算要么少算。原因工單沒有對BOM做版本快照BOM修改直接影響了在制工單。解決BOM表只做新增版本不做原地修改。每個工單創(chuàng)建時把BOM明細復制到工單BOM快照表后續(xù)查詢物料需求都走快照表而不是JOIN最新BOM版本。這樣做還有一個好處就是追溯歷史工單時可以還原當時的BOM到底是什么樣。這條準則同樣適用于工藝路線工單一旦創(chuàng)建工藝版本不可變更除非顯式做工序變更單。5.5 若依定時任務和MES輪詢任務并發(fā)導致工序超時誤報現象凌晨1點一批工單被自動標記為“超時”但是實際上班次是下午4點才結束。原因若依框架自帶的定時任務默認每分鐘掃描一次而MES工序超時檢測任務也是獨立調度的兩個任務并發(fā)執(zhí)行時超時檢測讀到了還沒落庫的班次結束事件。解決為超時檢測任務補充“班次結束時間校驗”邏輯只處理當前時間大于計劃結束時間加緩沖時間的工單。在若依的調度管理里把兩個任務的執(zhí)行錯開不要都放在整點。更重要的是給定時任務加上分布式鎖避免多實例部署時重復觸發(fā)。經驗是MES里的定時任務一定要允許手動補跑否則一旦漏跑超時狀態(tài)的數據補起來會非常費勁。6. 把SimpleMES從“記錄系統(tǒng)”變成車間看板先盯住一條小時產出SQL很多MES項目死在上線三個月后沒人看報表。要避免這個結局我的建議是不要一開始就做大而全的看板而是先盯住一條小時產出SQL。對車間主任來說今天現在這一刻產線干出了多少合格件比任何漂亮圖表都管用。-- 按小時統(tǒng)計各工序的合格產出和折算標準工時 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。很多實施項目把標準工時放在工藝路線表里工單工序實例沒有復制一份結果報表只能按數量統(tǒng)計算不了效率。工序實例落庫時把標準工時快照下來是我反復強調的一個點。報表穩(wěn)定后可以算極簡版OEE?？趶讲恍枰非蠛徒炭茣恢履苡镁托泻细癞a出數量乘以標準工時除以設備可動工時?？蓜庸r按班次時長減去計劃停機時間。這樣算出來的OEE有一個偏差但趨勢是可靠的。對比每天的OEE波動再結合不良代碼占比就能定位是哪個工序掉鏈子。等我回頭看這些年做過的MES項目凡是能堅持三周核對小時產出數據的車間最后都把SimpleMES用成了真正管理的抓手凡是只看月報的都半途而廢了。數據這種事你不能等它自己變準要拉著班組一起較真較真兩三個禮拜大家才認賬。希望幫到你。本文還有配套的精品資源點擊獲取