APC人機介面設計原則與電腦輔助分析機制探討

APC人機介面設計原則與電腦輔助分析機制探討

曹永誠

[刊登於電機月刊第178期 (2005年10月)]

前  言

APC（Advance Process Control；先進製程控制）是CIM系統中的一種，是由SEMI（美國半導體協會[1]）所定義與推廣的技術，目前常用於半導體與面板廠，對於FAB廠的產能與良率提升，具有很大的效益。APC系統因為其應用範圍屬於工程師的輔助系統，需求特殊，人機介面的優劣對於系統的效益影響很大，但是卻又很少有文獻對此題目進行探討，這是很可惜的事情。筆者以個人經驗與團隊研發的成果，針對APC系統的人機介面探討其設計原則與考量點，並提出一套我們團隊所研發的系統：電腦輔助分析系統-CAA（Computer Aids Analysis），這是目前我們獨特的創見，並非沿襲已久的技術與模式，期盼透過這些設計與技術以充分發揮APC系統的效益。

人機介面的重要性

人機介面（UI；User Interface）是使用者與系統或是應用程式AP之間的溝通介面，使用者透過人機介面來監控機台或製程、分析工程資料、挖掘問題，進而提高產能與良率。人機介面的設計要以效益導向，而不是以美觀導向，設計時要考量到使用者的互動性模式、是否隨處使用、系統反應時間、是否透過Internet以及考量其安裝成本等等，綜合考量之後選擇最恰當的方式設計。

以辦公室軟體而言，人機介面的設計優劣對於整個公司的運作，除了觀感上的喜惡之外，只會稍稍影響工作效率，增加少許的操作成本，但是對於APC系統來說，人機介面的優劣影響就很大。例如辦公室軟體中的MS-Word，主要的效用在於報告製作與文書處理，就算人機介面做的不盡理想，至多只會影響操作時間，不順手的操作讓工作時間拉長而增加些微的成本。但是對於APC來說問題就不只是這麼單純，因為APC主要的效益來自於透過機台連線、收集生產中的製程時序資料，然後進行分析改善製程，或是當生產問題發生時作為分析找尋問題的依據，因此不佳的人機介面所拉長的操作時間不僅增加操作人員的工時成本，並且會延後問題的發現時間，而這段延後的時間以半導體/面板廠的產能乘上單價，或是以損失的良率或產能來計算，損失金額可以說百倍於工時成本。此外，辦公室軟體（例如請假系統e-Form）就算人機介面設計的不好，至多讓員工不順手或是容易混淆產生錯誤。但是APC的人機介面如果沒有滿足工程師的需求，很容易就會造成誤判，或是因此找不出問題原因，無論是顯性與隱性損失都非常高。況且APC操作人員都是製程工程師或是設備工程師，並非純IT人員，他們對於電腦操作比較不擅長，而且操作APC系統只是工作的一小部分，熟練度很難養成，有時還得在無塵室內站立操作，因此如果沒有適切的設計，問題的發生機率就會大增。凡此種種，絕非單純坐在辦公室內專心設計程式的程式設計師能憑空想像周全的，但是以往APC的系統設計者往往只會從純IT的角度思考，尤其是人機介面的設計，通常只會根據自己常用的套裝軟體的經驗，模仿MS-Office、MIS/ERP或MES等系統的流程來設計，與使用者實際上的操作需求會有很大的落差，甚至導致使用者拒用系統等非理性反應。所以管理階層對於人機介面要能多加重視，程式設計師也不要閉門造車，適度的引進使用者參與共同開發，才能創造雙贏的成果。

人機介面的種類

人機介面的模式大致上分為三種：Rich Client、Thin Client、Smart Client。在以前大型主機（mainframe）的時代，電腦是很昂貴的龐然大物，得放在機房內運作。因此使用者只能透過終端機（Terminal）與大型主機連線，人機介面上的任何操作或是命令的下達都得傳回大型主機，由大型主機執行之後再傳回終端機顯示，Client端只具備顯示功能，這種方式稱之為Thin Client。隨著個人電腦PC的流行，使用者使用的電腦的運算與儲存能力越來越強大，因此應用程式AP的執行就慢慢的轉移到PC中，透過Client/Server的架構，由PC執行運算並與使用者互動，然後透過連結後端伺服器以存取資料庫，這種方式因為執行運算大部分都在 Client端，因此稱之為Rich Client。Rich Client模式提供了強大的人機互動能力、漂亮的畫面、彈性的操作（例如拖拉）以及快速的反應速度，可以算是使用者人機介面中功能與效率最強大的模式。最大的問題在於維護運轉成本過高，不管是第一次使用時系統安裝或是版本更新的成本，乃至於故障時的排除成本或是重新安裝等等，都會造成企業維運成本的大幅增加。之後，隨著Internet的流行與網路的普及，AP的使用不再只侷限於公司大樓內，在地理上的實際距離也大幅增加，因此Web Application（Web Form）就因應趨勢開始流行起來。透過Web Server與瀏覽器（Brower；例如MS-Internet Explorer）的結合，使用者不再需要安裝AP執行檔，只要直接在瀏覽器中輸入網址（URL），直接連接到遠端伺服器就可以輕易的使用服務。Web Application的人機介面處理方式很類似Thin Client，瀏覽器相當於大型主機時代的終端機，除了圖形顯示與字元游標處理能力比較強大之外，二者本質上並無太大的不同。就算是後期的n-Tier架構，透過BI（Business Intelligence）層擔任企業智慧處理服務，只要使用者採用的人機介面是透過瀏覽器，二者的本質就差異不遠。

採用瀏覽器的人機介面模式基本上也算是很好的介面，尤其是對於圖文並茂的文件瀏覽更是好用，而且不需要安裝也不需要版本更新，操作模式一致讓使用者幾乎不需要教育訓練就能上手。不過由於瀏覽器最初的設計是以文件導向，雖然佐以Script（例如：Java Script、VBScript）的協助可以提高些微的人機操作互動性，但是畢竟與應用程式AP的人機介面本質上差異很大，因此對於工程資料分析這類需要快速互動與複雜操作的模式，常常會感到力不從心。例如在趨勢圖中提供放大縮小等功能，就算是採用Script也很難達到，此時就得採用Smart Client的人機介面設計。Smart Client發展上大致區分為「獨立型」與「依附型」。獨立型是以新一代技術所架構，同時支援連線與離線模式的技術，目前可用的技術平台包括Microsoft .NET Windows Form、Sun J2SE WebStart與Macromedia Central。至於所謂依附型，則是依附在瀏覽器上，提供較豐富的使用者介面，但不能提供離線的運作能力，包括Macromedia FlashMX、AltioLive Platform、Droplets User Interface Server、Curl的Surge以及Avalon XAML[2]。以Microsoft.NET的Smart Client來說，基本原理是透過瀏覽器下載應用程式AP的執行檔，然後在瀏覽器中或是另外開視窗執行該AP，因為是採用應用程式執行檔的方式，所以互動性與操作性方面等同於Rich Client，可以提供強大的功能與高效率人機互動，而且是採用隨著瀏覽器自動下載與執行，並非使用安裝檔佈署到用戶端的方式，所以不用安裝、維護與版本更新，維護運轉的成本很低，因此頗為適合一些互動性高的AP採用。

  

APC人機介面

APC的人機介面主要提供使用者查看機台與製程狀態，或者是作為發生問題時找尋問題與解決問題的工具，大致上分為幾類：機台相關資料的整合與連接、製程時序資料的趨勢圖（Trend Chart）、FDC Rule的管理（新增、修改、刪除與使用狀況統計）、Run-to-run control參數調整、帳號與權限管理以及系統參數編修等等。所謂「機台相關資料的整合與連接」主要提供使用者以綜觀全局的角度來監看機台，整合數個系統的資料在同一個畫面之中，並且提供快速連接的功能。這種需求是因為CIM系統過於龐大，子系統種類繁多，而且由於採用分工開發或是採購導入不同市售套件，造成子系統之間的資料不一致而且分散在不同的應用程式與資料庫之中，所以當使用者想分析某一台機台或是製程時，就得「穿梭」在不同的系統之間找尋資料，並且使用「記憶力」與「想像力」自行整合在一起以綜合考量，很容易就會掛一漏萬。以FAB廠建廠導入程序來說，硬體土建與機台移入之後，MES（製造執行系統；Manufacturing Execution System）與EAP（Equipment Automatic Program）會先被導入，接著EDA（Engineer Data Analysis）、PMS（預防保養系統；Preventative Maintenance System）、RMS（Recipe Management System）等系統就會開始陸續開發與導入。而APC系統往往是最後開發與導入，尤其在8吋廠甚至於早期的12吋廠狀況都是如此。因此有機會能整合子系統之間的資料，讓使用者能在一個畫面中縱觀全局的大概只能由APC系統來整合與連接，整合的資料大致上包括機台Alarm紀錄、OOC（Out of Control）紀錄、PM（預防保養；Preventative Maintenance）紀錄、RMS中的Recipe更動紀錄、PAN（Process Abnormal Notification）等等。這些資料還是放在子系統各自的資料庫之中，只單純的透過對外介面將資料取出放在一起，透過適當的呈現方式提供使用者觀察機台或製程狀況。當然這些子系統的資料量都很大，如果想要將資料全部呈現，絕非一個畫面可以放的下，更何況放入過多的資料對於使用者來說只會造成混淆與疲憊，並不會有太大的好處。因此得依據需求慎重考慮要放入的資料欄位，然後保留超連結（hyperlink）到個別子系統，提供使用者在綜觀資料發現有不對勁之處時，可以點選後直接連到該子系統，更詳細的查看與研究細節資料以判斷與決策。

「製程時序資料的趨勢圖（Trend Chart）」是APC的被動系統中的主要功能，也是使用者最常使用的工具。基本上，APC系統分為主動與被動二部份，主動部份主要以Real-time FDC Kernel（即時故障偵測核心）、Integrate FDC Kernel（整合式故障偵測核心）、Run-to-run Kernel（批次控制核心）與報表系統等等，這些系統以服務（Service）形式在伺服器中執行，一天24小時不停的主動監控，並且於發現異常時通知使用者，或是直接停止該Lot、機台、Chamber、Recipe的執行，以確保壞貨損壞範圍不至於擴大；而所謂的被動系統主要是以人機介面方式提供使用者以互動方式檢查機台或製程，監控製程過程並且挖掘問題，然後編修法則或調整參數等等。被動系統的人機介面中最重要的工具，就是製程時序資料的趨勢圖（Trend Chart），本文將在後續章節詳細探討，並且提出更具威力的電腦輔助分析CAA（Computer Aids Analysis）提供更有效的分析輔助工具。

至於其他的項目，例如FDC Rule的管理（新增、修改、刪除與統計資料，如圖三）、Run-to-run control參數調整、帳號與權限管理以及系統參數等等。這些都是APC系統中比較需要客製化的人機介面，必須因應不同的系統與不同的工廠做客製化與調整，在本文中就不多做介紹。

以人機介面的種類來看，由於整合需求的緣故，APC系統建議儘量採用瀏覽器Thin Client方式（Web Application、Web Form）設計，除了CAA因為互動性與彈性的要求較高，Web Application 無法充分滿足需求以外，其他系統透過Web Application在系統整合與連結上會有很大的幫助。例如某個Lot在某個機台的趨勢圖，如果是採用Web Application型式設計就可以透過URL超連結該趨勢圖，因此當FDC偵測到OOC而發出Alarm email時，mail的內容就可以放入該URL，提供使用者點選查看。例如機台相關資料的整合時可以透過超連結（Hyperlink），提供使用者連接各個系統與機台，以最直接與便捷方式查閱資料（例如圖一的Alarm統計圖，透過點選可以Hyperlink到細部圖表或是Trend Chart趨勢圖）。至於CAA系統，由於該系統比較特殊，屬於工程師分析與診斷問題的離線批次分析工具，必須以各種方法與角度反覆分析，因此如果採用Web Application，使用上會變的比較不方便，而且由於系統回應速度變慢會造成分析效率的降低，所以建議採用Smart Client方式。筆者的團隊[4][5]是採用.NET的Smart Client設計，透過專用的CAA AP嵌入APC的ASP.NET Web Form網頁，連結整套系統並提供自動下載執行的機制，使用者並不會有切換系統時操作不一致的感受。不過APC的ASP.NET Web Form網頁與CAA AP的Smart Client之間如何透過類似Hyper Link連接，這是比較困難也是方案比較粗糙的地方，也是目前困擾的瓶頸。

製程時序資料的趨勢圖

APC製程時序資料的趨勢圖提供製程（Process）中的參數（SV）物理量所繪製的時間序列圖，操作流程大致區分為三步驟：選定資料、繪製Trend Chart與比對查詢。關於選定資料部份，各家的產品操作流程差異很大，依照不同的設計理念有著不同的選擇方案，各有其適用對象與優缺點。以8吋晶圓廠的架構來說，由於製程資料是以機台為單位存放，因此很簡單的想法就是直接選擇想查詢的機台；以12吋晶圓廠來說，大部分的機台製程資料卻是放在機房內用SAN等架構集中管理，因此切割與存放方式差異較大。比較簡單的想法也是以機台列表作為選取流程的前半段，配合實際的硬體配置讓使用者有直覺的操作，但是這種方式較為呆板，要求使用者來適應硬體配置的想法雖然沒有重大問題但是效益無法完全展現。原則上人機介面的設計要以滿足使用者需求來設計，而不是滿足現狀設計然後要求使用者去配合，所以建議的方案是前半段查詢要以使用者的需求來切割。APC的使用者主要為工程師，他們有組織上的編制與分工方式，每一組人馬有其負責的機台或製程，而他們使用APC系統查看資料與趨勢圖，目的也是對自己所負責的機台或製程，找尋問題或是確認運作狀況是否正常，因此資料選取的前半段要以機台或製程負責人組織圖來設計，透過List box分層選擇或是Wizard方式選定。而且由於使用者區分為設備工程師、製程工程師與工程資料分析三大類，前二者多半以所負責的機台或製程為關心重點，後者為了分析與診斷有時會有比較多樣的需求，例如取出某個Lot所經過的機台與製程的所有APC製程時序資料等等，三者的著眼點都不同，介面上最好提供三種不同的介面，分別針對個別的需求設計之。當選定了機台、Chamber或製程之後，後半段就得進一步篩選資料，例如選定時間範圍與Recipe（配方），然後從系統所列出的相關Lots ID中選取想查看的Lots與Parameter（SVID），之後才開始執行Trend Chart繪製的畫面。

使用者對於Trend Chart畫面最在乎的莫過於速度，雖然現在電腦系統速度很快，而且伺服器的等級又遠超過一般PC，但是由於APC的資料量實在太多了。以每秒對Chamber取樣一次來說，以一個FAB廠200~500台機台，資料庫的容量將會超過30T（1 Terabytes = 1000 Gigabytes）。如果沒有良好的設計與調整，使用者查詢的反應時間將會十分緩慢。雖然稍慢的查詢時間使用者還是能忍受，但是如果超過30秒還沒有反應，這樣的系統一定會慢慢的被使用者所嫌棄。一般來說，反應時間最好能控制在5~10sec以內。此外由於APC的查詢在某些時段會出現尖峰時間，例如生產會議前後等等，因此除了設計與測試正常流量之外，還得針對尖峰流量進行壓力測試並調整效率才行。

Trend Chart圖表面上看起來是很容易設計的功能，畢竟連Excel都可以輕易製作，但是實際上細節上是否合用才是關鍵點。首先，Trend Chart圖上的Zoom IN/OUT功能是基本需求，而且不是使用Text box輸入X/Y軸數值的手動方式，而是透過滑鼠拖拉直接Zoom IN/OUT的設計。這個需求在Rich Client（例如Windows Form）中輕而易舉就可以達到，但是對於Web Application在設計上就會比較困難，除非透過Java script / VBScript、APPLET或是.NET Smart Client等技術才能達到，但是因為這項功能非常重要，所以得想辦法完成才行。筆者的團隊是採用Dundas的Dundas Chart for .NET元件[3]，因為該元件採用.NET技術，所以只要Client端有安裝.NET Framework，就可以提供Zoom In/Out等功能。其次，Trend Chart圖的繪製模式要多樣化，至少提供四種模式：Series、Overlay、Parallel、長時間變異圖（Drift），如圖二所示。所謂Series是以時間軸將所有的資料繪出；Overlay是以Lot或Wafer為單位將資料重疊（Overlay）繪製Trend Chart，常用於Tools/Chambers match使用，或是在壞片問題找尋時的分析比對時使用；Parallel是將所要觀察的資料以Lot/Wafer為單位同時繪製在不同的視窗，並排在同一個畫面中；而長時間變異則是以四分位繪製，觀察長時間的漂移變異。此外，Lot/Wafer的相關資料最好能盡量標示在圖上，例如Step name，將製程資料中Step變換時間以縱向切分，或是用不同的顏色標註不同的Step；又例如 PM的時間點也必須標示於Trend Chart圖中，當Series模式時PM可以標註在Lots之間，當Overlay模式時則用不同的顏色標示PM前後，如此可以提供使用者同步考量PM對於製程的影響。又例如標註Recipe Change時間點或是Alarm紀錄的時間點等等，或是將FDC rule的管制線直接繪製到圖上。這些相關的資料與設定，如果都能適切的繪製到Trend Chart圖中，並且以時間點對齊的話，越可以提供更多更齊全的線索給使用者找尋問題，以降低誤判的機率。當然整合越多的資料，Trend Chart圖的查詢與繪製時間就越久，尤其大部分的資料都是其他子系統（例如MES、PMS、RMS）所提供的，因此如何最佳化與效能調整（例如事先批次載入等），就得與其他子系統開發團隊協調與修改。

樂觀的狀況是當使用者透過APC查詢資料並且檢視趨勢圖之後，就可以挖掘出問題，然後開始撰寫報告或是設計FDC Rule以監控機台或製程。然而實際上大多數的情況是使用者沒看到問題或只看到一些跡象但不確定是否為問題所在，這時候使用者就需要找尋其他相關資料比對或是佐證，例如查尋幾批同樣製程的Lot交互比對，或是另外一個同類型機台的資料對照。因此APC製程時序資料的趨勢圖要能提供簡單的查詢流程以調閱相關資料，供使用者作交叉比對使用。相較於第一次的查詢，比對用的資料必須要有更為簡便與快速的流程，以降低操作的繁瑣性，藉以提高操作效率。

電腦輔助分析系統

APC設計與導入的目的是為了提高良率與產能，因此得根據需求量身訂做，才能發揮最大的效益，但是也不能全部的系統功能都以客製化的方式進行，這樣會讓系統架構混亂複雜而且效率不彰，最佳的設計是在二者之間尋求平衡點，適切的分割底層平台（Plate Form）與上層應用功能（AP）。以Trend chart來說，前文所說明的都是屬於基礎功能，提供泛用型應用需求，也是APC平台不可或缺的子系統。但是為了進一步提升效益，APC必須提供更進階的分析與診斷人機介面AP，根據使用者分析與診斷需求，量身訂製系統規格，如此才能提供更高的效益。

目前我們團隊所設定的需求，主要在於當使用者鎖定某個機台的某段時間或是某幾批有問題的Lots，需要針對這段資料進行反覆分析的時候，提供使用者套用不同的分析法則與頻繁的互動操作功能，期盼能藉此挖掘出關聯規則或是診斷法則，並且進行規則編輯與測試等需求。針對這些需求，APC平台的泛用型Trend Chart在功能上就不敷使用，因此重新設計研發互動式的電腦輔助分析CAA（Computer Aids Analysis）子系統以因應所需。CAA子系統提供類似CAD/CAE功能，輔助使用者分析趨勢圖、挖掘問題核心，然後設計診斷法則讓FDC Kernel即時的診斷機台，捕抓未來可能發生的潛在問題。由於CAA子系統必須根據需求與經驗，逐步增加輔助資訊與相關演算法，因此無法一步到位囊括全部功能，我們團隊尚在逐步研發與更新版本，後文先就一些個案與各位先進分享。

首先，CAA子系統提供Trend Chart趨勢圖的量測功能。目前市售套裝產品都是將Trend chart圖設計成為單純的圖片，除了Zoom In/Out以觀察細節之外，在分析上並沒有任何輔助工具可以使用。CAA子系統是將Trend Chart趨勢圖設計成類似CAD的一組曲線，並提供輔助量測與計算的工具，以及繪製輔助線與標註等功能。例如使用者如果想知道Trend Chart中某段暫態的某個參數的上升速率，透過點選起點與終點，CAA子系統就會在Trend chart圖面上繪出一條輔助線並且標示斜率。又例如使用者可以圈選出某個區段並選擇穩定特性分析，CAA子系統就會算出區段的平均值與標準差，並且繪製散佈圖。這些輔助功能都是依照製程與分析人員的需求，逐一研發與導入。有些需求是由使用者自發性的提出，有些則是透過旁觀分析或是互動討論所規劃，然後整合與統一成為泛用型功能。但是因為不同的使用者有不同的分析流程與操作習慣，因此如果就使用者個別的想法直接規劃與套用，會讓整個系統的功能過多、成本提高、複雜度過高以及操作複雜，最後反而讓系統難以使用。所以我們的執行方法是透過觀察多個使用者在分析類似功能時的流程與操作習慣，整理之間的異同之後綜合考量，想辦法尋求最佳流程，這些流程與功能得保持一致性，並且避免使用上的混淆。最後再私下逐一溝通與開會確認，以製程角度就事論事討論，之後才開始程式設計與導入。如此方能順利開發與導入最合用且有效益的系統。

其次，CAA子系統提供數批Lots的比對輔助功能。針對同一張Trend Chart圖中的不同曲線（每一條線代表一個Lot或是一片Wafer，視繪圖模式而定），進行數學計算與比較分析。例如將一群曲線圈選起來選定穩態分析，CAA子系統會自動將這些曲線的平均值列表或是繪製散佈圖。如果使用者已經勾選標示壞貨，CAA子系統也會提供叢集分析與分群輔助資訊，如圖四所示。這些功能在低良率或是壞貨分析時，將是製程與設備工程師分析與挖掘問題的強大工具。藉由這些輔助資訊可以尋求故障分辨的規則，而且如果這些規則被驗證可行，還可以下載到APC系統的Online FDC子系統，即時監控製程避免問題再次發生。

最後，CAA子系統也提供故障偵測法則的模擬與驗證，只要使用者先將法則輸入並設定完成，CAA子系統會自動取出歷史資料，進行Run貨與APC資料擷取模擬。然後將模擬實際狀況後的資料，一筆筆的放入法則中驗證，最後顯示Out of control與Lot ID列表，或是繪製模擬發生OOC的Lot的趨勢圖，並標示管制線，藉此提供使用者進一步確認法則的正確性。而且如果使用者可以提供歷史壞貨的Lot ID列表， CAA子系統還可以分析法則的誤判率（Type I/II Error比率），提供使用者編修參考。

結  語

APC系統對於現在的高科技產業來說，已經是燃眉之急必須要投入開發與導入的系統，因為APC是工廠良率與產能提升的輔助工具，協助工程師進行資料分析與機台/製程診斷。透過APC工程師可以比較容易的挖掘問題，設計偵測法則，並讓APC系統24小時全年無休的幫我們看管機台與製程，監控系統防止再發生類似的故障，以降低損失提升良率。但是APC系統要能發揮效益，非得在人機介面上下功夫不可。因為唯有適切的人機介面才能讓使用者在分析時能得心應手，提高問題的發現比率。因此本文從APC平台基礎人機介面的設計法則，探討至我們團隊的創新成果：電腦輔助分析CAA AP的概念與功能介紹，期盼能拋磚引玉，更期盼各位先進的指教。

參考文獻

[1]. http://www.semi.org
[2]. http://taiwan.cnet.com/enterprise/topic/0,2000062938,20090633,00.htm
[3]. http://www.dundas.com/
[4]. http://apc.itri.org.tw/
[5]. 蕭禮明、陳玉雲、李正一、楊昌霖、蔡嘉鴻，"半導體製程監控系統介面之探討"，電機月刊，第162期，民國93年6月