製造AIの成否を分けるのはinfrastructureの数ではなく、少ない人員で継続運用できる構造です。 SPCとFDCは長く製造現場の基盤として使われてきましたが、製造AIを始める前に必ず両方を揃える必要があるわけではありません。
sensor dataと工程結果dataがすでに収集されていれば基本入力はあります。次に重要なのは、多数のdata、検知条件、model、control policyを誰が継続管理するかです。
- 重要なのはinfrastructureの数ではなく、少ない人員で継続運用できる構造です。
- sensor dataと工程結果があれば、SPC・FDCを両方持たなくても製造AIを始められます。
- 現実的な課題はmodelを作ることより、量産で継続運用することです。
- 準備状況を決めるのはFDC製品の有無ではなく、data connection、model operation、alarm policy、update structureです。
| SPC | FDC | APC | |
|---|---|---|---|
| 正式名称 | Statistical Process Control | Fault Detection and Classification | Advanced Process Control |
| 監視・利用data | 工程結果の平均とvariation | 圧力、温度、flow、powerなど装置sensor data | 工程結果またはVirtual Metrology結果 |
| 役割 | control chartで変化を確認しcontrol limit外を通知 | 設定range外のsignalを検知 | 次runで変更すべきrecipeやsetpointを計算・反映 |
| 異常発見後 | engineerがdataを確認し原因を推定して条件変更 | engineerがalarmを一つずつ確認 | control systemが補正を反復実行 |
SPC、FDC、APCが何を監視し、何を行い、異常確認後にどう対応するかを概念的に比較した表です。
FDCの問題は検知性能より運用にあります
核心はFDCがないことではなく、管理すべき条件が多く、工程変化に合わせて継続管理する人と時間が必要なことです。
FDCは装置sensor dataを監視し、設定range外のsignalを検知します。原理は単純でも、数百から数千のsensor変数をequipment、chamber、recipe、process step別に管理すると量産運用は急速に複雑になります。
正常rangeもrecipe、incoming wafer、maintenance、consumableの変化で変わります。
- recipeやprocess stepの変更
- incoming wafer状態やupstream historyの変化
- 装置状態の変化やconsumable交換
そのたびに検知条件を見直す必要があります。厳しすぎるruleは不要alarmを増やし、広すぎるruleは重要な変化を見逃しやすくします。
sensor signalごとにruleとthresholdを設定し、工程が変わるたびにruleとalarmを再調整する必要があります。
AI anomaly detectionにも結局運用構造が必要です
AI modelを導入しても運用問題が自動的に消えるわけではありません。
AI anomaly detectionは固定thresholdだけでなく、複数sensorの関係や時間patternを見て異常を判断できます。recipeや装置状態で正常rangeが変わる工程では柔軟に使えます。
それでも工程条件が変わればmodel validityを再確認し、maintenance、consumable交換、recipe変更後にはupdateが必要になることがあります。alarm priority、routing、retraining、replacement、version managementも運用対象です。
重要なのは一つの高性能modelではなく、多数のmodelを少ない人員で量産運用し続けられることです。
SPCは問題を見つけますが、解決は人に残ります
SPCの基本構造では、異常発見後の対応は人に残ります。
control chartがcontrol limit外の点を示した後も、判断とactionはengineerに残ります。
alarm後はdata確認から結果確認までを人が行います。APCはこのflowのかなりの部分を自動化します。
- dataを確認する
- 原因を推定する
- どの工程条件を変えるか決める
- 変更を次のproduction runへ反映する
- 結果を確認し追加調整が必要か判断する
SPCは工程結果の平均とvariationを監視するうえで有用です。ただしcontrol chartが問題を示した後はengineerがdataを確認し、原因を推定し、何を変えるか決め、適用して結果を確認します。
工程、装置、productが増えるほどこのloopにはengineerの時間が必要になります。SPCは変化を知らせても、原因判断と条件変更は別の仕事です。
APCはこのloopのかなりの部分を自動化します。工程結果またはVirtual Metrologyを使って現在stateを判断し、次runのrecipeやsetpoint補正を計算します。
計測結果が予測とcontrol decisionにつながり、計算した補正を次runへ反映して結果をtarget周辺に維持します。
APCが安定運用される工程では、SPCは品質確認や長期monitoringに残しつつ、実際の補正loopはAPCが担えます。
Infrastructureを構築することと自動化が完成することは違います
製造automationは導入system数より、どれだけ少ない人員で運用できるかを見る必要があります。
engineerが多数の条件を管理し、alarmを確認し、原因を分析し、modelを再検証し、update timingを判断し、工程条件を手動修正するなら、system追加は管理対象を増やすだけになり得ます。
- 一人のengineerが何台のequipmentとmodelを管理できるか
- 工程が変わったときsystemがどれだけ早く適応できるか
- 検知後の判断とactionまでどこまで自動化されているか
製造AIは既存infrastructureが完成してからだけ始める技術ではありません
重要なのは特定systemの有無ではありません。dataを接続し工程stateをmodelingし、工程変化後もmodelを維持して必要なactionへ安全につなげられることです。
SPCとFDCをすでに使っていれば、そのdataとinfrastructureを活用できます。完全に構築されていなくてもsensor data、工程条件、quality resultへアクセスできればAI anomaly detectionやAPCを始められます。
既存infrastructureはinputやintegration pointとして使えますが、必ず先に揃える前提条件ではありません。
Amouslyはprocess-data connectionからmodel development、validation、deployment、monitoring、update、control-policy operationまでを一つのflowで管理し、工程変化のたびにengineerが全条件を再設定する負担を減らします。