【智慧專欄】智慧製造的核心：AI 驅動的生產計畫

YouThought
2025年12月23日
讀畢需時 7 分鐘

作者：郭仲仁博士宇清數位智慧股份有限公司董事長暨首席技術長

傳統模擬已無法滿足現代生產計畫需求

半導體及其他高科技製造業的生產計畫（ production planning ）作業中，cycle time ( 生產週期時間 ) 的預測必須準確，才能精準預估每天的出貨量 ( output )，以確保客戶訂單的達交率，並避免因計畫預測失準，造成生產力損失。在過去二十餘年，許多半導體晶圓廠及顯示器面板廠導入美國或及韓國廠商的生產計畫系統，但最終多以失敗收場，主要原因在於這些系統採用離散事件模擬（ discrete event simulation ）技術做預測，在面對複雜的生產環境時，顯著暴露出其局限：

維護繁瑣：系統需要使用者維護大量機台及產品資訊，造成使用者的沉重負擔，有些系統為了修正預測偏差，甚至會要求使用者輸入本應由 Planning 系統計算出的輸出，例如 cycle Time，邏輯上站不住腳。
預測準確度不足：由於無法考量真實工廠中會影響 cycle time 的主要因子，模擬系統常低估 cycle time，進而高估產出 ( output )，或是高估 cycle Time，進而低估產出。且隨著時間推移，誤差會不斷累積擴大。
計算效率低下：傳統模擬需要對每個批次 ( Lot ID ) 與機台 ( Machine ID ) 之間的等候行為進行細緻運算，導致單次計算時間長達一天，難以因應即時調整的需求。
無法尋求最佳解：由於單次模擬耗時過長，無法在有限時間內測試大量情境，限制了基因演算法 ( GA ) 等最佳化技術的應用。

宇清的創新思維：從「產品步驟預測」轉向「機群預測」

以某半導體晶圓廠為例，該晶圓廠有 200 個機群 ( machine group )，生產 100 種產品，每個產品生產流程超過 1,000 個步驟，總計有超過 100,000 個「產品-步驟」( Product-steps ) ，每個步驟需要不同的機群加工生產。傳統方法，無論是離散事件模擬、統計迴歸，或是機器學習，皆是試圖直接去預測每一個 product step 的 cycle time ，卻忽視了機群才是影響 cycle time 的主要因素，不僅造成模型複雜，運算速度慢，更重要的是預測準確度很差。

據此，宇清數位智慧提出了創新思維：先預測此晶圓廠 200 個機群的 cycle time ，再根據機群的 cycle time 預測 100,000 個「產品-步驟」的 cycle time。此創新方法不僅可降低 AI 模型的複雜度，讓運算速度加快，更重要的是能夠大幅提升 cycle time 預測準確度。

影響機群 cycle time 的 KPI

Cycle time 由 run time ( 加工時間 )、 hold time ( 暫停時間 ) 及 queue time ( 等待時間 ) 組成。其中 queue time 是占比最多且波動最大的項目，因此是 cycle time 預測準確度的關鍵。

以下圖某機群為例，cycle time 的趨勢是往下愈來愈短，背後原因是 MPS ( master production schedule ) 的變化，造成此機群的負荷 ( loading ) 變輕，所以 queue time 及 cycle time 變短。

進一步分析，觀察到機台 uptime ( 妥善率 ) 的高低變化，會影響每天 queue time 的起伏。平日的 uptime 為 92 % ，queue time 為 0.351 天；而在假日，由於比較不會進行機台預防保養 ( PM )， uptime 會提升至 96 %，queue time 則降至 0.279 天。而假日後第一天，uptime 及 queue time 則介於前述兩者之間。

因此，要準確預測 cycle time，首先需要連結到 MPS，方能預測長期趨勢。其次，要預測 cycle time 的短期波動，則需要掌握機台 KPI ( Key Performance Indicators ) 的變化，例如uptime 。

除了平均 uptime， uptime 變異也會影響 cycle time 。以下圖一個非瓶頸機台為例，隨著平均利用率 ( Avg Uti. ) 增加，平均在製量 ( Avg Queue WIP ) 會非線性地增加。在平均利用率同為88%的點上，案例 A 的 WIP ( work in process ) 卻高於案例 B 。這是因為案例 A 的利用率變異很大（範圍從 82 % 到 94 % ），導致平均 WIP 高達 800 片。相較之下，案例 B 的利用率變異較小，平均 WIP 僅有 600 片。這說明了變異愈大， cycle time 愈長。

進一步分析，案例 A 將 PM 和 monitor ( 檢查 ) 都集中在白天，導致每小時 uptime 的變異高達 3 %。相反地，案例 B 將 PM 留在日班，但將 monitor 作業安排到夜班，uptime 的變異因此從3 % 降至 2 %，從而降低了利用率變異，因此減少了 WIP，進而縮短了 cycle time。

派工 ( Dispatching ) 也會影響變異，以下圖為例，上游 photo 工作區的派工如果追求自身的最佳化，極可能造成出貨在日班時偏重下游 etch 區，而夜班時則偏重在另一個下游 implant 區，結果造成下游的利用率變異升高， cycle time 因此雙雙增加。

因此，想要準確預測機群的 cycle time，除了應考量平均值的 KPI (例如 uptime ) 也應包含變異型的 KPI ( 例如 uptime 變異 )，宇清定義了會影響 cycle time 的 24 個完整 KPI ，如下表所示 ( 本文僅列舉部分代表性 KPI )。

Machine Learning 預測 cycle time

收集每個機群超過 365 天的歷史資料，包含輸入項 KPI 以及輸出項 cycle time ，以機器學習 ( machine learning ) 技術 ( 例如:倒傳遞類神經網路 ) 訓練模型。第一個模型，如下圖 A 模型，透過資料訓練找出每個機群 KPI 和 cycle time 的關係。在全部的 24 個 KPI 當中，有 8 個 KPI 會影響每個 product step 在此機群的相對 cycle time ，因此需要建立第二個模型，如下圖 B 模型，透過資料訓練找出 KPI 相對值如何影響 product step 在此機群的相對 cycle time ( relative cycle time )。

當每個機群的機器學習模型訓練完成後，可以依據以下 4 個步驟，預測每個 product step 未來每一天的 cycle time :

Step 1 : 預測機群 arrival 、 BOH 及 KPI

連結 MPS 以及 on-hand WIP ，預測每個 product 每天的投料量 ( job release ) ，並預測每個機群未來每一天的 arrival 、 BOH 以及 KPI 。

Step 2 : 預測機群 cycle time

運用訓練好的模型，以預測每天的 KPI 做 what-if 分析，預測機群未來每一天的 cycle time (A) 。

Step 3 : 預測 product step 相對 cycle time ( B )

依據每個 product step 的相對 KPI，預測其相對 cycle time。

Step 4 : 預測 product step cycle time ( A x B )

將 step 2 的預測結果 ( A ) 乘以 step 3 的預測結果 ( B ) ，得到每個 product step 未來每一天的預測 cycle time。

某半導體 12 吋晶圓廠 A 原本自行發展的系統，預測未來 90 天的 cycle time ，準確率僅有 85 %，在導入宇清的AI生產計畫系統後， cycle time 預測準確率大幅提升至 98 %，而且 day-to-day 的 correlation ( 相關係數 ) 高達 0.62 ，如下圖所示 :

訂定合理 target move ，準確預測出貨

為了滿足目標出貨，提升達交率，工廠會依據每個 product step 的 critical ratio 來決定瓶頸機群產能的分配，進而訂定每個 product step 的 target move ( 目標產出 )。 Critical ratio 愈低，代表產出將落後，應該訂定較高的 target move 。

因此，若是 cycle time 預測不準，critical ratio 就不是正確的，訂出的 target move 就是瞄準在錯誤的目標，最終導致 output 預測不準。

如下圖所示，某半導體 12 吋晶廠 B 在導入宇清的 AI 生產計畫系統 u-Planning 後，將 product step 的 target move 交由宇清的 scheduling 系統 u-Optimizer 執行，以確保將會達成每個產品的目標出貨量。比較導入前後，預測出貨準確率由 86 % 提升至 96 %。

MPS 模擬與最佳化

由於運用完整 cycle time KPI 簡化了機器學習的模型，宇清的 AI 生產計畫系統 u-Planning 能在連結 MPS 訂單需求與 on-hand WIP 資料後，20 分鐘即可產出投料計畫及預測出貨日，並預測機台的負荷、WIP 以及是否有冗餘的 WIP ( redundant WIP )。