製造 AI 成敗的關鍵不是 infrastructure 有多少，而是能否用有限人力持續運行。 SPC 與 FDC 長期以來都是製造現場的重要基礎，但不代表一定要先把兩者都建好，才能開始製造 AI。
如果 sensor data 與製程結果資料已經在收集，基本輸入條件就已經存在。接下來更重要的是，誰來持續管理大量 data、偵測條件、model 與 control policy。
- 關鍵不是 infrastructure 的數量，而是能否用有限人力持續營運。
- 只要已有 sensor data 與製程結果，即使沒有同時部署 SPC、FDC 也能開始製造 AI。
- 現實挑戰不是做出 model，而是讓 model 在量產持續運行。
- 是否能開始取決於 data connection、model operation、alarm policy、update structure，而不是是否擁有 FDC 產品。
| SPC | FDC | APC | |
|---|---|---|---|
| 正式名稱 | Statistical Process Control | Fault Detection and Classification | Advanced Process Control |
| 監控／使用資料 | 製程結果的平均與 variation | 壓力、溫度、流量、功率等設備 sensor data | 製程結果或 Virtual Metrology 結果 |
| 作用 | 透過 control chart 觀察變化，超過 control limit 時提示異常可能 | 偵測超出設定範圍的 signal | 計算並套用下一次生產需調整的 recipe 或 setpoint |
| 發現異常後 | 工程師確認 data、推測原因並修改製程條件 | 工程師逐一確認 alarm | control system 持續進行補償 |
概念上比較 SPC、FDC、APC 監控什麼、做什麼，以及發現異常後如何處理。
FDC 的難點不只在 detection performance，而在 operation
核心問題不是沒有 FDC，而是要管理的條件太多，而且製程改變時需要持續投入人力與時間維護。
FDC 監控設備 sensor data，偵測超出設定範圍的 signal。原理不複雜，但一台設備可能有數百甚至上千 sensor，還要依 equipment、chamber、recipe 與 process step 維護不同標準，量產營運很快就會變得複雜。
正常範圍也會因 recipe、incoming wafer、maintenance 與耗材狀態改變。
- recipe 或 process step 改變
- incoming wafer 狀態或 upstream history 改變
- 設備狀態改變或耗材更換
每次變化都需要重新檢查偵測條件。設定太嚴會產生大量無效 alarm，設定太寬又可能漏掉重要異常。
每個 sensor signal 都需要 rule 與 threshold，而製程改變時，rule 與 alarm 也需要重新調整。
AI anomaly detection 最終仍需要 operation structure
導入 AI model 並不會讓營運問題自動消失。
AI anomaly detection 不只看固定 threshold，也能一起分析多個 sensor 關係與時間 pattern，因此在正常範圍會隨 recipe 或設備狀態改變的製程中更有彈性。
但製程條件改變時仍要重新確認 model validity。maintenance、耗材更換、recipe 修改後可能需要 update，alarm priority、routing、retraining、replacement、version management 也都要管理。
重要的不是做出一個高準確度 model，而是讓多台設備與多個製程中的 model 都能用有限人力持續量產運行。
SPC 能找到問題，但解決仍留給人
SPC 的基本結構，是把發現異常後的處理留給人。
control chart 顯示超出 control limit 的點之後，後續判斷與 action 仍留給工程師。
alarm 發生後，從確認 data 到確認結果仍由人完成。APC 會自動化這個 flow 的很大一部分。
- 確認 data
- 推測原因
- 決定要修改哪個製程條件
- 把修改套用到下一次 production run
- 確認結果並判斷是否需要進一步調整
SPC 對監控製程結果的平均與 variation 仍然很重要。但 control chart 發現問題後，工程師仍要確認 data、推測原因、決定要改什麼、套用修改並再次驗證。
製程、設備與產品越多，這個 loop 就需要更多工程師時間。SPC 能告訴你有變化，但原因判斷與條件修改仍是另外的工作。
APC 可以自動化這個 loop 的很大一部分。它利用製程結果或 Virtual Metrology 判斷目前狀態，並計算下一次生產應調整的 recipe 或 setpoint。
量測結果接到預測與 control decision，計算出的補償值套用到下一次生產，使結果維持在 target 附近。
當 APC 能穩定運行時，SPC 可以保留做品質確認與長期 monitoring，而重複的製程補償由 APC 負責。
建好 infrastructure，不代表 automation 已經完成
評估製造 automation 時，比起裝了幾套系統，更應該看能否用更少人力持續營運。
如果工程師仍要維護大量條件、逐一確認 alarm、分析原因、重新驗證 model、判斷 update timing，並手動修改製程條件，那麼新增 system 可能只是增加更多管理對象。
- 一位工程師能管理多少 equipment 與 model？
- 製程改變時，system 能多快適應？
- 從 detection 到 judgment 與 action，有多少已經自動化？
製造 AI 不需要等既有 infrastructure 全部完成才能開始
重要的不是某個特定 system 是否存在，而是能否連接 data、modeling 製程 state，並在製程改變後持續維護 model、把必要 action 安全接下去。
如果已經有 SPC 與 FDC，可以沿用既有 system 與累積的 data，不需要全部替換。反過來，即使 SPC 或 FDC 尚未完整建置，只要能取得 sensor data、製程條件與品質結果，也可以開始 AI anomaly detection 與 APC。
既有 infrastructure 可以是輸入與 integration point，但不一定是必須先完成的前提。
Amously 把 process-data connection、model development、validation、deployment、monitoring、update 與 control-policy operation 放在同一個 flow 裡，減少製程每次改變時工程師重新設定全部條件的負擔。