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