在PC/PLC整合的控制系統中建構Ladder自動診斷機制
曹永誠
[刊登於機電整合雜誌第82期 (2005年6月)]
前 言
隨著時代的進步，機臺設備也得越來越聰明（smart）。除了製程或加工的精度與速度要不斷提升之外，自動化的需求也變成必要功能，此外機臺的自我診斷機制也將是未來的發展趨勢。最常見的案例為影印機，隨著影印室人員的縮編，影印機的操作變成一般員工直接使用。面對數量龐大的操作者，公司不可能花費巨資教育訓練，或是編列預算聘請服務人員於旁指導或是協助排除故障。因此影印機的設計就得越來越smart才行，除操作介面採用圖型化人機介面（GUI）以降低操作的困難度之外，當卡紙時還會以圖型顯示機臺狀況與卡紙的位置，甚至於用動畫告訴使用者如何開蓋排除。這些圖型化人機介面的設計，就是為了因應時代潮流，讓影印機脫離受過訓練的操作人員，直接打入普羅大眾的市場。對於機臺設備來說，二者的概念是一致的，所不同的是影印機透過人機介面降低維運成本，而機臺設備則需要更進階的功能以提高產能並減少維護成本。也就是說影印機的效能提升重點在於使用方便與故障排除的簡便性，節省教育訓練費用與服務人員成本；而機臺則在於需要一組機制自我診斷內部狀況，偵測是否發生故障與發生問題的零組件位置，讓維護工程師可以儘早維修，降低故障所造成的損失與產能下降。在本文中筆者提出一套方法，透過PC端來監控與診斷PLC Ladder執行狀況，讓機件故障時能儘早發現與通知工程師維修，並盡快確認問題發生的零件而不需採用試誤法（try and error），提高維修的效率縮短停機的時間。這套方法最初是為了東捷科技(股)公司的IC tester handler機臺所設計，成效證實不錯。希望能藉此拋磚引玉，並期盼先進的指教。
背景描述
PLC（Programmable Logic Controller；可程式化控制器）對於工廠內惡劣的環境（如高溫、粉塵與高雜訊）防禦能力很強，市售廠牌與機種很多而且功能齊備，所以在機臺設備的控制系統中被廣為使用。PLC的主要設計語言為Ladder（階梯圖），雖然新一代PLC多半提供更高階更強大的控制語言（IEC 1131），但是由於機臺開發廠商的電控人員，對於PLC傳統控制語言Ladder（階梯圖）的熟練度較高，外加新舊機種的相容問題，因此無論如何Ladder仍然是目前PLC最受歡迎也是最普及的控制程式語言。當初PLC與Ladder的出現主要在於取代硬體繼電器（Relay）接線式的控制電路。雖然Relay控制電路簡單易懂好用，但是體積大、價格高而且配線時間長。因此Relay控制電路在設計考量上就得儘量精簡與最佳化，也就是說要儘量減少Relay的個數與接線數。但PLC的Ladder是採用微處理機（CPU）解碼，透過PLC的作業系統（OS）的解譯器（Interpreter），以掃描（Scan）方式執行Ladder程式碼。因此雖然PLC Ladder圖與Relay配電圖二者外觀上十分相似，而且PLC的變數名稱也叫Relay，但是卻不是真的硬體Relay元件，而是PLC中記憶體所模擬的變數。所以，PLC內的Ladder程式長短並不會與成本絕對相關，只要在一定的限度之內，PLC等級並不需要因此更換而造成成本增加。
因此在這種情況之下，設計與維護成本就變成考量的重點。也就是如何以合理的時間與人事成本，設計穩定、高品質且強健性好的PLC Ladder，而且易讀易懂易瞭解，讓日後維護、修改與擴充成本降低，才是考量的首要重點。因此傳統Relay配電盤的最佳化方法不再適用，個人工藝式的創意也不是好方案，因為以個人創意所最佳化設計的Ladder程式有以下缺點：(1).沒有一定的設計規則，日後很難了解設計考量點；(2).修改與除錯困難；(3).系統交接不易；(4).技術傳承困難，技術難以累積。
目前工業界流行的PLC Ladder設計手法是採用狀態圖設計[2]。以狀態圖方法所設計的PLC Ladder不但簡單清楚，圖（程式）也易懂好維護。當然比起最佳化Relay電路，程式長度會比較大，不過面對PLC容量普遍很大的情況，程式長度並不會造成問題。而且如果運用恰當，狀態圖除了順序控制之外，還可以設計if … then … else …與if … then … else if … then … else …，甚至於for-loop、while-loop等電腦結構化程式語言的功能都可以輕易設計出來。
雖然透過程式設計技巧，狀態圖也可以達到結構化程式語言的近似功能，但是在多工處理方面，卻有其難以突破的瓶頸。相較於MS-Windows系統的多執行緒（multi-thread），Win32 API所提供的WaitForMultipleObjects()函數，有部分的功能就是狀態圖所難以做到的。因為狀態圖對於Timeout機制不夠完整，雖然可以用分支的方式為每一個狀態點設立Timeout分支，但是一方面將會大幅的增加Ladder程式長度，增加程式的維護成本；另一方面Timer/Counter的個數有限，除非採用很特殊的設計方法，否則難以實施。所以目前的設計法則，大多數是將Timeout機制用於少數比較重要或是特定的用途上，或是整串順序控制整體執行時間的監控。例如機構中真空吸盤部份，由於真空吸盤的失敗率比較高，因此需要Timeout機制分支處理吸取失敗的狀況；或者是比較容易出問題的機構，例如壓PIN的氣壓缸，由於工件規格公差等問題，經常會發生卡料等情況，這時就得加入Timeout分支做卡料故障排除的順序控制。另外一種常會使用的情況是針對模組大功能的順序控制，往往會加入Timeout機制監控以確保各個大功能命令的順利執行。
以狀態圖的設計規則來看，每個狀態點的進入條件絕大部份都是外部I/O Sensor（Ex. 極限開關或氣壓缸上的磁簧開關）或是其它模組的完成訊號（Ex. 馬達模組的點對點運動命令完成訊號），雖然大部分的Sensor都很耐用也不容易出錯，但是在工廠內長期運轉，必然有其出錯與故障的可能性。如果此時沒有任何的Timeout機制以偵測問題，則該狀態點將會無止盡的持續等候，而下個狀態點的進入條件永遠也不可能成立，因此機臺將無任何警示訊號的停止運轉，等到操作人員發覺不對，機臺怎麼會顯示正常運作卻無任何動作時，機臺已經不知道停機多久了。更糟的是當維護工程師趕到現場時，一時間也很難判斷到底是那個Sensor或是外部模組出問題，得一個個逐一測試才能找到問題點。這種狀況不但耗時且會造成生產線停擺的停工損失。若再遇到該Sensor尚未完全故障，訊號是處於快要壞掉偶而出錯的情況之下，檢修與排除的成本就更加高昂了。目前的作法是在機臺每個獨立大功能的一串順序控制的開始與結束之間，設計Timer機制以保護整串的程序確保最長執行時間。但是這種方式只能保障機臺不會當機當的無聲無息、毫無預警而已，當某個Sensor故障之後，依然需要人工逐次檢查Sensor或是接上Notebook檢查Ladder執行狀況。
此外，由於PLC的容量比PC受限大，加上PLC Ladder的程式設計比起PC的程序語言不方便，因此電控工程師在順序控制的設計上，比較不會針對各種可能的例外與錯誤，都做檢查以提高強健性。以圖一為例，當X軸要移動時，Z軸必須先上升到定位才能移動，以確保不會撞機的安全性。其狀態圖的設計大致上會分為二個狀態，首先先下達上升命令，然後開始檢查上方感測器（例如氣壓缸的磁簧開關），等到上方感測器ON確認Z軸已經上升到定位，才能進入下一個狀態點，下達X軸移動的命令。但是如果上方感測器在一開始就是故障狀態，或許因為壽命或是其他因素短路，或是I/O Relay黏住的狀況，則在第一個狀態點（下達Z軸上升命令並等到上方感測器ON），會在命令一下達的下一個瞬間立刻收到上方感測器ON的訊號，因此會立刻結束這個狀態進入下一個狀態，開始下達X軸移動的命令。但是實際上Z軸尚未真正完全上升，因此會容易造成機臺撞機。比較好的設計是在上升Z軸的狀態點前，先檢查上方感測器是否已經ON；或是上下方感測器是否同時ON，因為這二個感測器的訊號應該是互斥的；甚至檢查上方感測器ON的時間是否過快，遠超過機構本身的最快移動時間等等，以確保機構運作的安全性。但是因為PLC的容量有限而且Ladder設計比較不方便，因此目前真正實施的比率不高。
圖一、簡單的機構與狀態圖
Ladder自動診斷系統
以目前的應用來說，很多機臺設備的控制系統多半是PLC與PC（或IPC）整合的系統：PLC直接控制硬體與機構，負責程序控制與排程程序；PC則與PLC連線通訊，負責系統整合、人機介面與對外通訊的部份。由於PLC對於環境的強健性，以及機械工程師對PLC Ladder比較熟悉的緣故，加上PLC本來的設計目的就是為了順序控制使用，因此在各個模組都使用專屬的PLC擔任模組控制器執行順序控制。然後在機臺控制中心設置PC為主控制器，透過網路與各模組PLC連線，執行系統整合、模組排程、操作員人機介面，並提供對外通訊介面（例如SECS、HSMS）。針對前面所列出的PLC Ladder瓶頸問題並期望能提高系統強健性，在控制系統為PC-PLC整合式架構的前提之下，筆者設計了一組Ladder自動診斷系統模組來改善。設計基本概念為在PC端設計一組診斷系統，透過通訊連線讀取PLC內部Relay與I/O值，透過事先設計的Rule設定檔，自動診斷PLC Ladder的執行狀況以提高系統強健性，主要功能有三項：
- 自動偵測每個狀態Timeout，當Timeout發生時主動送出建議的檢修資訊給使用者。
- 診斷順序控制的錯誤：理論上同一組順序控制同時間只能有一個狀態致能。不過由於PLC Ladder採用Scan方式執行，因此如果狀態圖的發生次序撰寫成PLC Ladder後，仍採用由前到後次序的時候，在狀態致能切換的瞬間有時會發生二個狀態點同時致能的現象，但是這只是在一個SCAN時間的暫態並非穩態，以濾波器或簡單的法則就可以去除。因此在穩態的情況，如果一個獨立模組順序控制同時間有二個狀態致能的時候，一定有系統性的錯誤（但是有例外狀況），例如Ladder程式的Bug或是其它故障。這時候機臺就得停機檢修，並由人機介面將問題點（同時存在的狀態點）提供給工程師維修參考。
- 監控互斥訊號：對於互斥訊號，診斷系統得隨時檢查確保是否正確。例如氣壓缸二端的磁簧開關，正常情況是不可能同時ON，除非接點短路或是黏住等電氣或機器故障，否則不該有這種現象。所以Ladder自動診斷系統會透過網路隨時監控這些訊號點，確保其互斥狀態。當發生問題時會主動通知控制系統停機警訊，並且將發生問題點顯示以供檢修工程師參考。
對於獨立模組的順序控制來說，狀態圖的狀態點同時間只能有一個狀態成立（致能），也就是說這些狀態點各自的自保電路的Relay應該都是互斥的（除非特殊程式撰寫方法）。因此PLC Ladder程式設計者要另外編一份「互斥點列表」，將這些不能在同時間ON的Relay編號都設定成同一組。當Ladder自動診斷系統開始運作時，會自動將此表載入，然後透過連線不停的讀取Relay值，自動檢查同一組的Relay是否有同時ON的狀況。但是因為Ladder採SCAN方式，因此瞬間同時ON的暫態現象是可以被容忍的，因此當連續N次（N值可以設定，內定值為3）發生同時ON的狀況時，就會透過標準介面將停機與警示訊號送出，而這警示訊號內容就是同時ON的Relay編號與註解。當然「互斥點列表」除了可以針對自保電路的Relay進行互斥監控之外，對於需要監控互斥的I/O點也可以放入此表中，只是這些監控因為採用網路連線外部監控，因此取樣頻率低，對於高速狀態的互斥監控無法適用。對於高速狀態的互斥只能使用PLC Ladder程式進行偵測。
系統運作流程
Ladder自動診斷系統分為二大部份：Rule編修系統、自動診斷核心。如圖二所示，Rule編修系統為外部獨立執行檔，提供人機介面給PLC Ladder程式設計師編修診斷的Rule，主要分為二部份：「狀態點容許最長時限表」、「互斥點列表」。「狀態點容許最長時限表」提供Timeout機制以監控Ladder狀態圖執行情況診斷與回報；「互斥點列表」提供Ladder在程式層次的檢驗，確認同時間只能有一個狀態成立，以及互斥型I/O點的檢查，保障I/O故障時的基本保護機制。當PLC Ladder程式設計師將這二份設定檔都編修完成之後，Rule編修系統會將這些Rule以INI格式儲存（後期改寫成XML格式，不過功能相同），供自動診斷核心載入使用。當然編修Rule設定檔需要花費不少時間，而且與PLC Ladder程式的同步更新也是需要管控的麻煩事，但是因為當時並沒有辦法取得PLC Ladder程式檔案的編碼規則，無法透過程式自動產生設定檔，所以才會採用手動的方式編修。如果能取得Ladder檔案格式，甚至於Plug-in Ladder Edit軟體同步產生Rule設定檔，這將會是更好的作法。自動診斷核心為一組函式庫，提供PC端主控程式使用。當主控程式第一次啟始自動診斷核心，參數中要傳入Rule設定檔名與路徑，自動診斷核心就會將Rule設定檔載入使用。此外，主控程式也得提供一組PLC Relay讀取介面，因為PLC模組不單只有自動診斷核心會使用到，在模組排程或是人機介面顯示方面都會隨時讀寫PLC Relay。因此如果讓自動診斷核心直接對PLC通訊，勢必會造成衝突與混淆，因此應該統一由PC端主控程式對PLC通訊讀寫Relay，然後提供標準介面給各個模組使用，為求方便起見可以採用Global函式。當自動診斷核心將Rule設定檔載入之後，首先得掃描整個Rule設定檔，取出所有要監控的Relay點編號，聯集並去除重覆點，然後取出讀取範圍，透過主控程式所提供的標準介面，整批方式每秒讀取一次後再解開應用，如此可以得到比較好的效率。所有使用到的Relay都採用I/O Mapping方式紀錄與使用，而Rule部份則是以二組Struct Array方式運作，當每秒啟動一次的Timer啟動Callback函式之後，自動依照新的Relay值更新I/O Mapping，然後開始依次掃描Rule的Struct Array，逐一檢查是否有問題發生。
這套模組在東捷科技(股)公司的Logic IC Tester Handler機臺上首次開發使用。這組機臺採用三菱A系列PLC當成模組程序控制器，然後以IPC當成主控制器負責排程與人機介面。Handle機臺非常複雜有十個伺服軸與五百多個I/O點，而且IC物料的規格的公差不小，因此高速運轉時卡料的情況常常發生，也就是在真空吸盤的狀態部份因為卡料、掉料與吸取失敗的機率不低，所以在PLC Ladder之中已經設計Timer機制偵測Timeout與故障排除分支，並且提供故障排除人機介面。但是在導入Ladder自動診斷系統之前，還是常會出現機臺突然不動但是又沒有警示的狀況。因為工廠內的作業員一個人得管好幾部機臺，如果機臺沒有故障警示或是出料訊號，作業員一般來說是不會主動去查看機臺是否正常運作，因此遇到這種狀況往往會讓機臺「掛」在那直到交接班才被發現並通知工程師處理，而工程師也沒有足夠的訊息可以快速排除故障或是更換組件，往往得錯誤嘗試多次之後才得以排除，因而對於設備廠商的形象會造成不良的影響。為此需求才追加開發了這套「Ladder自動診斷系統」，並導入安裝使用。因為該機臺PLC與PC之間是透過RS422通訊，因此這套診斷系統佔用了不少通訊頻寬，試機初期的確讓機臺的效率有些下降。後來針對狀態圖的Relay重排，儘量將監控點集中於某一段區域，而診斷系統核心函式在PLC Relay的讀取方式，也改用區塊批次讀取方式，並且將診斷時間更改為每秒一次，之後對於機臺效能的影響就變的微乎其微，而且機臺無故「掛掉」的情況也不再發生。有鑑於這項機制十分實用而且應用範圍很廣，後來就改寫程式並且模組化，成為可以重用的元件後推廣使用。
圖二、Ladder自動診斷系統示意圖
結 語
以目前科技的進步與世界的潮流來說，機臺的自動診斷必定是未來的趨勢。本文所建構的方式為筆者數年前所設計的模組，對於PC/PLC整合的機臺控制系統來說，提供了簡單而基本的診斷機制。單以機臺維護運轉來說，簡單好用而且導入快。目前筆者所帶領的團隊[7] [8]研發的診斷機制來自於APC/AEC（Advance Process Control/Advance Equipment Control；先進製程控制/先進設備控制），透過資料收集與資料分析，使用統計或類神經網路等等手法，進行FDC（故障偵測與分類；Fault Detection and Classification）、OEE（Overall Equipment Efficiency）、e-Diagnostic等等[6]。APC/AEC是由半導體業開始發展，由SEMI所制定的標準[5]，目前在FAB、TFT、III-V族等產業很多廠商都已經開始研發與導入。在傳統產業方面，雖然目前尚未開始流行，但是時代潮流未來勢必朝向這個方向走。因此筆者透過本文，期盼能拋磚引玉，由Ladder診斷著手，之後有機會的話再陸續介紹APC/AEC的概念與技術，希冀能帶動相關技術，並期盼各位先進的指教。
參考文獻
[1]李正金芳，可程式控制器原理與應用，全華科技，1986/7[2]姜禮展，PLC狀態控制設計法，工研院課程
[3]邱清城，三菱可程式控制器電腦連線原理，全華科技，1997/9
[4]沈文智，PC通訊技術與實務，波心資訊，1993/9
[5] SEMI, “Equipment Engineering Capabilities Guidelines (Phase 2.5)”, SEMI International Standards, July 2002
[6] James Moyne, Arnon Max Hurwitz, Enrique Del Castillo，"Run to Run Control in Semiconductor Manufacturing"，Lewis Publishers, Inc. (November 30, 2000)
[7] 徐明照、曹永誠，"Run-to-run control簡介與APC framework架構設計"，機械工業月刊，第258期，民國93年9月
[8] http://apc.itri.org.tw/
沒有留言:
張貼留言