前一章處理的是設備、PMC Server、資料庫與 API。到了應用層，重點變成另一件事：這些資料到底能不能減少現場原本需要人工查詢、抄寫與比對的工作。

因此這一章不把每一套功能都稱為「AI」。有些工作其實只是把工單和機台資料接起來，有些是歷史值比對，有些才會使用演算法。只要能解決現場問題，就有它存在的價值。

Author: Jush Li

4.1 射出製程資料整合平台

射出現場的資料原本可能分散在紙本、Excel、ERP、機台控制器與不同資料庫裡。每一邊都有資料，但要查同一張工單時，往往需要再人工拼起來。

製程資料整合平台的工作，就是先把這些資料放到同一個生產背景下：這筆資料是哪張工單、哪一個產品、哪台機器、哪副模具，以及發生在什麼時間。

4.1.1 網頁操作介面

現場人員不需要直接操作資料庫，也不必自己輸入大量設備資料。介面主要負責建立生產任務，以及補上機台無法自動取得的資訊。

工單與模具關聯

系統從既有資料來源取得製令單號、品號、品名與模具編號。操作員開始生產前選擇對應資料後，就能建立這一段生產紀錄。

後續不論是機台自動取得的 Cycle Time，或人工填寫的不良數量，都可以回到同一張工單查詢。

製程與材料資訊

依產品與機台需求，可記錄穴數、成品重量、料骨重量及其他必要條件。

如果機台端已經能自動取得壓力、溫度、射出速度、塑化時間或冷卻時間，就直接使用設備資料；機台沒有提供的欄位，再由人工補充。

品質與備註

有些資訊不適合做成固定數值，例如「首件尺寸確認後才可量產」或某次調機的特殊狀況，仍保留備註欄位讓現場記錄。

圖 4.1-1：成型管理紀錄介面

每一筆紀錄至少要能留下時間、工單、機台與相關數值。這樣後續查詢時，才不會只看到一堆不知道發生時間與來源的參數。

4.1.2 以 RESTful API 串接前後端

前端頁面不直接操作 ERP 或底層資料表，而是透過 RESTful API 取得需要的資料。

例如工單、機台與成型紀錄可分別透過固定資源取得，前端只需要依 API 格式讀取，不必知道資料實際存在哪幾張資料表。

{  "id": 12,  "orderNo": "MD20250617",  "machineId": "NEX-V360",  "cycleTime": 12.34,  "parameters": {    "injectionPressure": 230.0,    "holdPressure": 45.6,    "barrelTempZone1": 240  },  "quality": {    "goodCount": 480,    "rejectCount": 2,    "remarks": "首件OK"  },  "timestamp": "2025-06-17T08:10:00Z"}

JSON 的好處是 Web、Python、.NET 或其他程式都容易處理。但真正重要的是欄位定義固定，例如 cycleTime 是秒還是毫秒、timestamp 使用哪個時區，都應該先定義清楚。

4.1.3 OpenAPI (Swagger) 互動式文件與測試

API 一多，如果只靠工程師口頭說明，很快就會出現版本不一致。

因此透過 OpenAPI 定義 Endpoint、參數與回傳格式，再由 Swagger UI 顯示文件。前端或測試人員可以直接查看目前 API 的實際規格。

這樣新增欄位或修改路徑時，比較容易確認前後端是不是使用同一個版本。

4.1.4 小節

這一層真正解決的是資料分散問題。工單、人工紀錄與機台參數先能放到同一個生產區間裡，後面的品質分析與異常監控才有依據。

4.2 PHP RWD生產報工系統

機台聯網之後，系統可以知道目前 Cycle Time 是多少，卻不一定知道現在正在生產哪張工單。

報工系統補的就是這一段。

操作員開始生產時，把工單、產品、模具、人員與機台建立關聯。從這個時間點開始取得的設備資料，就能知道屬於哪一段生產。

4.2.1 現場報工操作

圖 4.2-1：RWD 報工操作介面

生產開始

操作員選擇製令單、品號、模具與機台後開始報工，系統留下開始時間，並建立這一次 Production Session。

之後機聯網讀到的 Cycle Time、模次或其他資料，就能透過機台與生產時間對應到這張工單。

人工資料補充

機台不會知道產品是黑點、流紋還是其他外觀不良，因此良品數、不良數與異常原因仍由操作員或品管輸入。

自動資料與人工資料各自處理擅長的部分，比要求所有資訊都由設備自動判斷實際。

RWD介面

系統使用網頁式 RWD 設計，可依現場設備在電腦、平板或手機瀏覽，不需另外維護多套 App。

4.2.2 生產日報與查詢

圖 4.2-2：生產日報表查詢介面

報工完成後，管理端可依日期、品號、機台、操作人員等條件查詢。

同一筆紀錄裡，可以同時看到人工報工資料與機台資料，例如生產時間、Cycle Time、良品、不良品與備註。

如果後端另外保存完整製程資料，也能再從工單時間區間往下查詢對應的機台數值。

4.2.3 小節

報工系統最重要的功能不是讓現場多填一張電子表單，而是建立工單和機台資料之間的時間關聯。

有了這個關聯，後面才能回答「某一張工單當時實際 Cycle Time 是多少」這類問題。

4.3 Cycle Time 異常預警

Cycle Time 是射出現場最容易取得，也很容易理解的指標之一。

但只看「現在是 35 秒」沒有太大意義。真正有用的是知道這個產品在這台機器上，過去正常生產大約是多少。

4.3.1 系統概覽與示意

圖 4.3-1：Cycle Time 超出設定範圍時，以紅色標示

1. 先確認現在生產什麼

預警前提是知道目前機台對應的品號、工單與模具。否則拿錯產品的歷史 Cycle Time 來比較沒有意義。

2. 建立歷史 Cycle Time

系統保存相同產品與機台過去的週期資料，作為後續比較基準。

基準如何更新應依實際規則設定。若某次生產本身就是異常資料，不宜直接把它混進正常基準。

3. 比較目前與歷史紀錄

機台完成循環後，系統將目前 Cycle Time 和對應歷史值比較。超過設定範圍時，在頁面上標示異常。

4.3.2 從預警回到現場確認

圖 4.3-2：目前機台數據監控

Cycle Time 變長的原因很多，可能是冷卻時間調整、機械手等待、操作員動作、材料、模具或其他生產條件。

所以系統的角色是先把偏差大的機器挑出來，讓現場知道哪裡值得先看，而不是直接替師傅判定原因。

若有保存歷史趨勢，還可以分辨是偶發一模，還是 Cycle Time 已經連續一段時間往上。

4.3.3 系統價值與效益

• 減少人工逐台查看： 先將超出基準的機台標示出來。
• 留下時間紀錄： 之後可查異常是從哪個時間點開始。
• 搭配工單追溯： 確認 Cycle Time 異常發生在哪張工單及產品。
• 累積正常基準： 相同產品下次再生產時，有歷史數據可比較。

4.3.4 小節

Cycle Time 異常預警本身不複雜，但它很適合作為射出廠第一個即時異常功能。

因為數值容易取得、現場也看得懂，當它和產品、機台與歷史資料接起來後，就能比單純顯示目前秒數更有用。

4.4 GA 生產排程

射出排程難的地方，不只是工單很多，而是一張工單能去哪台機器，通常還受到模具、機台噸數、交期、換模、材料與現場狀態限制。

因此本系統使用基因演算法（Genetic Algorithm, GA）先產生可用的排程方案，再由生管依現場狀況調整。

4.4.1 GA 預排

圖 4.4-1：GA 初始預排甘特圖

GA 的做法不是算出一個「絕對最佳答案」，而是反覆產生與比較不同排程，從中找出分數較好的方案。

一個排程方案可以包含工單順序、指定機台與開始結束時間，再依工廠實際需求設計評分方式。

• 交期延遲。
• 總完工時間。
• 換模次數。
• 機台可用條件。
• 模具與機台相容性。
• 其他工廠自己設定的限制。

經過多次 Selection、Crossover 與 Mutation 後，系統保留較合適的方案，再以甘特圖呈現。

4.4.2 手動微調:RWD+RESTful API的彈性掌控

圖 4.4-2：排程清單微調與拖放介面

演算法不知道所有現場細節。例如某副模具今天剛好維修、某台機器臨時停機，或某張工單客戶突然要求提前。

所以 GA 產生的結果仍保留人工修改。生管可以調整順序、換機或插入急單，再把修改後的結果更新回系統。

若需要，也可以針對受影響的區段重新計算，而不是每次都整張排程全部重做。

4.4.3 效益與價值

相較純人工排程，系統最大的差異是先處理大量重複的條件比對。

排程人員不必從空白表格開始，而是從已經算過一次的結果往下調整。

急單進來時，也比較容易知道插入某台機器後，後面的工單會受到哪些影響。

4.4.4 小節

GA 在這裡是一個排程工具，不需要把它包裝成完全自動的 AI 生管。

系統負責把可以量化的條件先算一遍，現場人員負責補上系統目前不知道的事情，兩邊配合反而比較符合實際生產。

4.5 行動倉儲 RWD 網頁介面

倉庫作業另一個常見問題，是現場已經拿到材料或成品，卻還要回到固定電腦才能查詢或輸入 ERP。

因此行動倉儲介面改成網頁式 RWD，讓人員直接在材料或貨架旁查資料、收料與盤點。

4.5.1 即時物料追溯與動態查詢

圖 4.5-1：物料查詢

QR Code 最主要的用途是快速帶入識別資料，減少人員手動輸入品號或批號。

掃描後再由系統查詢 ERP 或 WMS 中對應的庫存資訊。QR Code 本身不需要放入所有庫存資料，只要能正確找到那筆資料即可。

4.5.2 倉庫收料:現場完成入庫登錄

圖 4.5-2：倉庫收料

收料時先掃描對應標籤，系統帶入品號、單據與數量，再由倉管確認實際收到的資料。

確認後才寫入庫存，省掉現場先紙本登記、之後再回辦公室重複輸入的流程。

收料與庫存異動屬於寫入操作，因此還需要搭配登入身份、操作權限及異動紀錄。

4.5.3 即時盤點與差異調整

圖 4.5-3：即時盤點

盤點時可直接在現場輸入或掃描實際數量，再和系統庫存比較。

有差異時先標示出來，再依公司權限流程進行調整，避免盤點人員掃描後就直接修改正式帳面庫存。

4.5.4 成品入庫與追溯管理

圖 4.5-4：塑膠射出客製化入庫

成品入庫時，如果包裝或標籤已有工單、品號與數量，就可以透過掃描直接帶入，不必重新輸入相同資料。

入庫資料再和原本的報工紀錄建立關聯後，後續查詢時可以知道這批庫存來自哪一張生產工單。

4.5.5 小節

行動倉儲的目的不是另外再做一套 ERP，而是把倉管真正需要的幾個操作帶到現場。

查料、收料、盤點與入庫若可以直接在貨架旁完成，就能少掉一次紙本或回辦公室重複輸入。

製程平台負責整理資料，報工建立生產情境，Cycle Time 負責找出值得注意的週期差異，GA 協助排程，而行動倉儲則把生產後的物流資料接回系統。

這些功能不一定需要一次全部導入。對射出工廠來說，先把最常發生重複輸入、最難追查或最耗人工時間的流程做好，通常比一次做很多功能更實際。