廠務系統穩定運轉–桶槽用量管理

前言

由於半導體製程越來越精密，所需使用的化學品及氣體用量也越來越大，因此如何確保供應無虞變成一項重要的課題，廠務系統中除了氣體化學課供應大量的化學品外 ，也尚需要處理設備製程所產出的廢化學品；因此確保原料供應無虞及廢液收集順利清運都是需要重視的，否則將造成生產停線的問題。

所有的廠務系統都可以設定液位的即時警報，但透過廠務系統SCADA系統設計三階警報將造成SCADA的負擔同時也花費更多的Tag資源，因此，透過一個桶槽管理系統除了能達到三階分級警報的設計外，同時可以運算區間用量並且透過運算預估可用時間，因此可以擴大系統的應用。這裡所討論的三階警報系統係針對目前廠務目前負責層級所設計，第一階警報是一個通知資訊，告知值班人員必須要通知物流公司排定車次進行補料或是廢液清運，因此，值班人員對於這個警報簡訊必須有感，並且在收到訊息之時便通知相對應的公司負責人員排運補車次；第二階段的警報是一個真的警報必須通知到該課的副理層級，表示用量已達警戒值，一般這個警示也就是設定在SCADA上的Lo或是Hi警報，通知副理必須要關心這個事項並且追蹤狀態；當系統達到第三階警報時則代表供料將發生問題，因此會通知到部經理層級，這是一個Critial Alarm必須要動員處理，否則將斷料而造成供應的問題，必須要緊急應變 ，確認是否槽車運補發生問題或是任何可能的原因。

由於物料的使用與廢液的排放的管理無須以非常即時的資訊處理，因此，在系統中使用十分鐘為一個執行單位 ，這樣可以降低系統的負載並且也避免因為液位波動造成大量的警報產生。系統的設計係依據系統的需求而設定運算時間，這個部分與各課系統工程師討論而訂定出執行時間，而資料則是透過廠務最重要的InSQL即時資料庫系統進行處理^[1][2]，為了達到即時的目的因此透過DIP Raw Data交換技術並搭配MSSQL進行最佳運算模式與分析^[3]，並以此建構一個即時可行的系統讓系統的運作能夠更順暢以提供即時而正確的資料。

文獻探討

廠務原物料用量管理首要重點在如何讓大量使用的原物料確保供應無虞，因此應加強原物料的用量及存量管制模式，即時監控安全存量，快速通報用量資訊，即時通知原物料廠商派車及廢液清運，物料存量管制之主要目的即在「決定適當的訂購時機與訂購數量」達到穩定供應零中斷。依台肥刊物文章：物料管制及原料供應規劃，一般常用之存量管制方法有下列四種^[5]：

2.1.兩堆式控制法

一般來說，工廠的工控系統可能遭遇的潛在資安風險有下述兩種：

• 此種存量管制方法係將同一項材料分置兩個倉庫或兩個儲位，當其中A倉庫材料用完時，即提出請購，另繼續使用B倉庫材料，等A倉庫材料進廠時，B倉庫材料已用至接近安全存量界限，等B倉庫用完再提出B倉庫之請購 。
• 此存量管制方法適用低價物料且物料配送快速。

 2.2.兩堆式控制法最高最低存量控制法

• 最高存量與最低存量是根據企業內部之經營策略，並參酌每項物料之耗用計錄、未來用量與需求量預估而訂的 ，物料的正常存量就維持在最高存量與最低存量之間。庫存超過最高存量的部份應即時檢討處理，低於最低存量時，亦需儘快補充。茲以勿料的真正需求經常會改變 ，最高存量與最低存量也必須適時修正。
• 此存量管制方法適用低價物料且物料配送快速。

 2.3.定量請購控制法(廠務用量管理主要參考作法)

• 所謂定量請購控制法，是指材料庫存到達某一固定量( 即請購點)時，就依設定之經濟訂購批量(Economic Order Quantity, EOQ)提出請購。而訂購點的存量=前置時間內之耗用量+安全存量。另安全存量之高低與物料需求是否穩定及前置時間能否掌握有關，當物料的需求量及前置時間愈固定時，安全存量愈可能降低。
• 此類方法適用於耗用量穩定之物料。

2.4.定期請購控制法

• 每隔一段時間(每週、每月、每季)即請購一批物料，以補充存量，請購週期固定，請購數量則不定，要依該請購週期之預估用量及現有庫存量(包括已訂未交量)之動態與安全存量，決定當期之請購量。即請購量+現有存量+在途量+安全存量≦最高存量。
• 此一存量管制方法適用於重要庫存價值高且請購次數頻繁的物料。

廠務用量管理系統係依廠務原物料用量特性，與系統課充分討論，歸納出廠內原物料使用量穩定，需求量及前置時間也很固定，因此參考定量請購控制法為管理系統設計主軸，即時監控用量變化，嚴守安全存量，快速呈現即時資訊，達到某一固定量自動通知值班人員訂購及廢液回收時機點，達成穩定供應目標。

研究方法

用量管理在目前階段係針對桶槽管理討論，如前言所述，由於300mm化學品用量大增，相對的廢液的排放量也大增，因此設計一個系統針對桶槽的管理，無論是用量或是排放量都是必須的；同時也依循三階警報管理的模式設計整個系統，每一個階層的警報針對不同層級的人員通知以達到分層負責的目標，讓對的人處理相對應的事項。

這個系統的設計也是依據InSQL資料設計，因此為了達到效能與即時性，採用了與可靠度管理相同的技術，因此，這裡不再贅述這個技術，而是針對系統設計說明讓讀者能掌握這個系統設計的方式與精神。

3.1.資料架構設計^[3]

桶槽管理的系統架構設計￫圖1，透過sisTank這個主資料表來記錄桶槽即時資訊，及運算之後的相關數據，即時資訊來源是sisRaw這個即時更新的資料表，由於系統設計係以十分鐘為一個周期，因此，透過MSSQL的Task設定於每十分鐘固定執行一次，每次針對每個桶槽做運算，因此當發生警報時資訊會記錄在sisTankAlm這個資料表內，而使用者可以透過提供的介面輸入桶槽的備註說明，這些輸入的資訊則是記錄於sisTankCmt內；而這個系統也依據設定運算桶槽的用量，這些計算的用量歸類在UMP這個系統內，因此相關的資料表如圖中所示的umpTankRaw；其餘的資料表則是存放用量的Baseline、換算後的化學品用量等資訊，以完整提供使用者參考的依據，因此除了即時用量的管理外，系統也提供長期用量的觀測。對於系統建構來說，依據討論的邏輯設計出邏輯流程之後，接著便是設計適當的架構圖，由於這個系統應用關聯式資料庫系統進行運算與應用，因此適當的資料架構關聯圖就能夠簡化系統的設計，也就是一個良好的系統資料架構圖除了可以簡化系統開發的難度外，同時也能夠讓系統的透明度大量提升。

圖1、Tank Management系統架構

3.2.系統邏輯與運算

依據桶槽的類型可區分為原液與廢液兩類，因此在￫圖2中我們使用原液類型的使用模式進行說明。一個桶槽再灌充滿液位之後就不會有警報存在，而隨著物料使用讓液位開始降低，最後分別可能引發Level-1、Level-2、 Level-3等三階警報，圖中顯示了兩階警報的液位示意圖，而第三階的警報則是更低的液位達到設定值時則會引發；另外，圖中也顯示了L1D的示意圖，當Level-1警報已經觸發了，因此系統引發警報並且通知值班人員，但是在達到第二階警報之前在設定的時間內尚未灌充，此時系統會引發一個L1D的警報，也就是說三階警報是依據液位引發，而L1D則是依據液位與時間兩個因素引發，目的是通知值班人員注意低液位並持續一段時間超過預期應該灌充的時間，因此值班人員要針對這個項目注意，以避免液位過低而再次引發第二階警報。而廢液的運算模式則是相對的使用高液位進行控管，同樣也會因為已經第一階液位警報但未清運達到一定時間而引發L1D警報。

圖2、桶槽使用模式圖

而￫圖3則是一個判斷的流程圖，系統針對資料中的每一個桶槽分別進行判斷，當然首先要判斷這個桶槽是原液桶槽或是廢液桶槽，程式分別針對Level-3、Level-2、 Level-1設定值依序進行比對，當最高層級的警報已經發生了，其餘的也就不進行運算，也就是已經達到Level-3的警報則不再判斷Level-2及Level-1；若有警報則再判斷是否為Redundant桶槽，目前系統設計最多可為三個複聯桶槽，當複聯桶槽有任何一個為正常時則目前的桶槽僅會引發Level-1的警報，縱使前面已經判斷出更高層級的警報，因為系統仍能正常供應，只是需要通知系統值班針對著個桶槽進行叫車補液。而L1D也是Level-1警報發生時，並且L1D的時間值大於0才會進行判斷，當持續時間大於設定時間時才引發L1D的警報；這些警報都會被記錄並且觸發警報通知相關人員。

圖3、桶槽運算流程圖

因此，系統人員應該了解系統特性並且適當設定三個等級的液位，同時設定適當的L1D時間以更加強系統控管 ，讓補液或是廢液運補能夠適當進行，避免任何可能的生產影響。

3.3.用量運算模型

系統針對每個桶槽的用量計算日用量並用以預測目前餘量可使用時間，因此套用一些運算的邏輯進行日用量的運算，依據與使用者討論結果，這個運算方式適用於每天頂多運補一次的桶槽，因此系統每天運算兩次。

￫圖4中顯示幾種無法運算的情況，當12小時的使用有兩次的灌充或是連續灌充都無法運算；這是以原料為例時的項目，廢液的圖形則是相反的方向。

圖4、用量運算無法使用的模型

在一般的狀況下，透過不同的邏輯運算可以計算出區間的用量，￫圖5中顯示了這樣的模型，當區間用量一直下降則可以由前後兩個數值計算用量；第二個情形則是計算的過程中進行灌充，或是第三種情形計算開始還在灌充階段，並且在區間內灌充完成，降低的期間可以計算用量，而灌充期間則計算時間，並使用降低期間的時用量乘上灌充區間的時間則可估計這段時間的用量，兩者相加後就計算出這個時段的用量。因此12小時內不能灌充兩次也不能連續灌充12小時，否則邏輯就無法套用。

圖5、用量計算的模型

3.4.系統設計與開發

經過以上的步驟與討論，整個系統內最重要的部分都已經齊備，最後以廠務熟悉的程式設計模式進行設計，廠務系統大部分採用Windows，MSSQL，ASP.Net架構開發系統，因此，這套系統我們依循著開發，為了達到效益，主程式放置在MSSQL裡使用Stored Procedure開發，因為是MSSQL內嵌程式因此應用MSSQL的性能會更好，透過 Task的安排，讓系統可以每分鐘更新一次，達到類即時的目的；而介面方面則採用ASP/ASP.Net開發^[4]，這個平台普遍用於廠務大部分系統，可簡化維護的工作，並且降低開發與維護成本。￫圖6中展示了判斷三階警報的程式片段。這個系統透過即時取得的數值與系統工程師設定的三階警報數值進行比對而定義出不同等級的警報，程式中也顯示了系統預先判斷是否在複聯正常狀態，當複聯狀態正常則僅會做第一階的警報，這就是依據前段的邏輯設計以程式來實現系統的運作，並且搭配資料架構完整記錄資訊因而讓系統設計更簡單，除了容易維護也讓未來的維護者可以很容易就知道系統如何設計，當邏輯有所調整時也不需要大費周章修改。

圖6、MSSQL Stored Procedure邏輯處理的片段

￫圖7則顯示了系統如何在固定時間運作，利用MSSQL的Agent代理程式可以設定Task，而Task就依據我們設定的時間固定運算，因此所設計的Stored Procedure完全整合資料庫系統，Task也就是資料庫的協同運作程序，整個系統經由MSSQL就能完成，無須額外撰寫程式，效能也能達到一定水準而達到即時監視的目的。

圖7、MSSQL Task 設定自行運作

結果與分析

透過Web作為顯示介面，不但方便瀏覽，使用者所需的資訊在原本的DIP系統中使用了Dashboard的概念，資訊亦可以一目了然，固定時間(每10分鐘)更新的狀態顯示在介面上，相關人員於公司內任何可登入tsmc電腦即可開啟網頁瀏覽，￫圖8顯示了這樣的一個結果；這兩個Dashboard分別顯示桶槽狀態及桶槽警報資訊，第一個Dashboard告知使用者目前系統L1、L2及L3目前數量，可瞬間掌握桶槽現況; 第二個Dashboard則是提醒使用者目前桶槽基本資訊 ，包含L1警報逾時、警報隔離數量、以及桶槽數值未更動 ，以不同的面向提醒使用者依據不同角度關心所屬系統。

圖8、網頁瀏覽Dashboard

現況300mm各廠已完成導入此功能，200mm奕是如火如荼的進行fan-out，此功能也開門十件事平台其中一項 ，如￫圖9所示。

圖9、開門十件事資訊整合介面

於Dashboard上可在依據顯示的數值，展開至更細項資訊，以符合各個層級的需求；￫圖10中，顯示了桶槽資訊列表並顯示目前值、日用量、是否需要叫車(原物料採購點或廢液排放點)等細項資訊，讓值班人員能迅速掌握那些有問題的桶槽。

圖10、檢視詳細結果

結論

系統尚未建置前，主要問題在於由人員確認不但load -ing問題會浮現，也無法達到一天24小時每10分鐘定時確認，而桶槽的用量管理主要目的是取代人力判斷的不足，透過廠務資料庫系統即時取得資訊，並應用討論所得的邏輯，系統設計為三階層警報分別針對值班人員、課級副理級部門主管進行簡訊通知以避免斷料的風險，靈活運用程式自動化且不間斷的偵測的特性並輔以邏輯判斷使值班人員於第一時間即可收到異常通知，此異常不僅僅偵測安全存量，亦包含了用量過少、廢液過多等等做即時監控，主管僅需要於每天夕會交接時review，或發生問題時開始系統畫面，便能一目了然完全掌控狀況，並於需要派車補原液或清運費液的時機點，自動通知至供應商及清運商，供應商及清運商即可提前安排調派運送車輛，值班人員僅需與廠商確認狀態即可，於系統上線後至今，並無再發生因桶槽未確認到而發生供應中斷的問題，透過系統課與FMCS合作，管理面及監控面的整合設計，完成此套系統 ，也讓系統工程師了解系統管理在監控中如何運用，同時FMCS人員可深入各個系統運行的關鍵，更加以發揮所長 ，因此能更加深入各個系統，而此系統目前僅針對大型桶槽做管理，未來可擴大討論至氣化課的小型Drum桶供應原物料的控管，讓原物料用量管理更全面完整。