20210313情境B

尚未解決疑問：
若可在Site-1裡解決為何要到別的Site。(ANS:Change Recipe Cost)
Foop經過的路徑為何(例：機台->暫存區->天車->機台?)
晶圓作業大概時間？
Storage carrier可以1-1 stocker或是1-多 stocker?

問題假設：
一、 蝕刻2 Current From 目的地為別的Site
二、 情境B JOB = Foup(20 or 25片晶圓)
三、 情境A Ave. Wafer Output / hr = 一台Stocker平均產出wafer數
四、 更動目的地(暫時不管，無法定義)

說明:
queued的foop在stocker，不在OHT上
current的在OHT上運送

問題說明及情境分析：
一、82-11 = 71台OHT分配給Queued、Delay、改變目的地...

二、因蝕刻1(Bay8、Bay1)的Occupancy Ratio偏高，且根據情境A表格數據顯示，顯影Scanner的生產效率比蝕刻1高，且機台數更多，因此在蝕刻1的部分一定會塞車。

預期效益：

HI~
A0 應該是要先弄懂那些製程在幹嘛 然後設計一個可以讓派工順暢的方法。猜的。

Q1 我們現在選擇情境B，輔以情境A的參數作為參考。首先情境A的(1-ave.availability)是指在change recipe或是cold down嗎？下面的ave. wafer output/hr 是「考慮上面三列條件」所平均出來「每部機台」或是「每項製程」的每小時wafers？ 因為網路上找不到晶圓在各製程的作業時間，只知道一筆訂單應該要兩三個月才能完成，所以很難估算。

A1 availiability 應該不只有change recipe跟cold down, 還有一些其他人為維護機台也會影響。一筆訂單由多組製程完成，通常有上千道製程，可以想像成很多個stock。

Q2 情境B題目說明中提到執行中有359個job，我們看出來是右上方四列表格加總；Queued兩列加總則是排隊準備執行的233個job數量，而被終止、已延遲與待更動目的地的job數都從右方的表格中卻看不出來，不曉得這些有隱藏在表格中的數字之間的嗎？

A2 感覺要從從表格上的四個from/to/current/delay kpi仔細推敲，應該會比可以算出題目上的終止跟延遲的數據。方向應該是他表格上的數據是某一個特定時間的狀態，下一秒表格上的數據應該會轉換。

Q3 目前我們大致了解晶圓在前段製程是需要重複經歷這四大項程序，但不了解的是每經過一次loop後是不是要更換一次recipe？這可能就是解釋為何同屬於PR的Bay1與Bay3的Current To為0，也同時要假設ETCH2製作完成的CurrentTO應該都是要送往別的廠區？

A3 可以想像成做完一次jobs就會更換recipe。ETCH2做完會到量測站(題目沒列出他的目的地時間先假設去別場了)，之後再重PR那段開始。

Q4 情境B右下角的表格也讓我們有些疑惑。同為ETCH1的Bay8與Bay10所配置的Storage Carrier及Storage Upper Limit比例非常奇怪。配合情境A的產能比較表，推論ETCH1一定會塞車，但目前還沒有理由解釋為何這樣配置。成大的這篇論文中有引用2000年的一篇期刊，說到晶圓倉儲使用率上限約為70%，個別晶圓倉儲使用率超過上限則需要第二座晶圓倉儲。可惜這篇論文好像被刪掉了，各大院校的系統都找不到，即使破解付費網站也被導引到別篇，所以沒法從原文理解。不知道是不是這二十年間在倉儲這塊有突破性的進展，不然應該不可能2020還犯了20年前提出的毛病。

A4 工廠裡面混亂的事情很多，你可以列出來，感覺你找到瓶頸處了哈哈。我對派貨不太熟，但題目確實要找瓶頸 跟解決方法，或許可以往那個方向去思考，找出瓶頸應該要看那些kpi(例如剛說的70趴）,當kpi達到的時候，會用怎麼樣的建議調整派貨（或是加機台來解決）。可以反覆驗證（或是多Google看看有沒有其他數據輔助）滿確定數字怪的話，應該就是你找到瓶頸了。