機台控制系統軟體開發效率提升探討

機台控制系統軟體開發效率提升探討

曹永誠

[刊登於電機月刊第162期 (2004年6月)]

前  言

隨著消費性電子產品快速世代交替的需求，相對應的機台開發時程也被嚴重壓縮並仍被要求準時交機，因此機台設備廠如何因應趨勢提升新機種開發效率與品質並且確保準時交機，將是日漸重要的事情。就短期來看，如何在不降低品質與縮減功能的前題之下準時出機，以掌握瞬息萬變的市場與商機；以及就長期而言，如何能自陸續開發的機種間，累積自有技術並持續提升專案執行效率，減少機台開發所需時程與人力，這些問題的答案將是機台設備廠商的競爭力來源。因此本文試圖就問題的根源，探討機台設備廠商開發採用PC-Base控制器機台時，在控制系統的軟體開發方面，如何透過適當的規劃開發專案與長期技術整合應用，來解決前述問題。

機台開發專案

以機台設備廠來說，新機台的設計與製作需求總是持續不斷。一方面，不同的客戶因為生產線與產品規格的差異性，必須以現有機種客製化修改，或是當單純的修改無法滿足客戶的需求時得訂製全新機台；另一方面，由於順應公司未來的發展方向﹑新製程的開發或是產業的趨勢與技術的升級等所產生的需求，都將必須主動開發全新機台以開拓新市場維持公司競爭力。一般來說，公司的新機台或新機種的開發都會以專案型態（project）執行。如圖一所示，以時間軸來看新機台專案的需求與執行並不一定會平均分佈，有時候新機台開發團隊（或部門）會同時執行二個機台的開發專案，人員必須分配到二個不同機種的開發，因此就有可能會發生專案執行需求人力衝突；或是某件工作只有少數工程師能執行，但是同時間進行的專案卻同時需要執行這份工作。有些時候也可能會發生沒有專案需要執行因此部分人力閒置；或是部份人力很忙部份閒置，但是由於技術背景不同又幫不上忙。或是突然間的專案執行決策，造成同時間的機台開發專案排定過多。這種時緊時鬆﹑無法預期﹑人力需求波動與不平衡的現象，對於新機台開發團隊（或部門）來說已經成為工作的常態。

因為機台的種類很多，不同種類的機台開發模式與最佳化考量不盡相同，因此本文探討的內容暫以PC-Base的多軸全自動化非工具機類的機台為範疇。以這類的機台開發來看，雖然開發的機台個別規格與時程差異性很大，但是專案的執行流程卻大致雷同。如圖二所示，新機台的開發需要三大類人才-機構工程師﹑電控工程師與軟體工程師，分別負責機構設計組裝測試﹑配電設計製作裝配與控制系統軟體設計測試。當專案開始執行時，大多數的狀況是由機構工程師主導進行系統規劃，由整機的功能面與機構動作來考量，釐清系統規格與機構擺設配備。在這階段電控工程師也參與討論與協助設計，包括軸數﹑配電與配電箱在機台位置的擺設；而軟體人員則同步規劃因應功能的人機介面，以樹狀圖設計功能項目，擬訂機台操作流程與軟體架構。當機構規劃完成，機台規格﹑擺設與機構動作流程定義清楚之後，機台開發專案就會進入第二階段系統設計，機構工程師著手設計組立圖﹑拆圖繪製加工圖，然後發包加工與跟催。在此階段電控工程師負責協助機構工程師選配所需要的伺服馬達，針對I/O點﹑A/D點﹑D/A點與伺服軸等配電需求設計配電圖與配電箱，並且發包製作配電箱；軟體工程師則依照功能﹑操作流程﹑機構動作程序等規格程式設計與模擬測試。當機構外包加工的零組件陸續完工交件之後，機台開發專案就進入第三階段組裝測試。在這階段機構工程師（或組裝工程師）開始進行機構組裝；電控工程師同時協助配電與試電。當機台組裝大致完成，機台開發專案就進入第四階段機台測試驗證。機構工程師會對機台的機構部分進行測試與修改；電控工程師配合測試接點與調整感測器位置﹑微調感度；當機台的組裝與測試進度到達可以局部運轉時，軟體工程師就可以安裝控制系統軟體，測試機構動作程序控制﹑排程程序﹑人機介面各項功能﹑操作流程﹑整機手動/自動運轉與故障排除等等。當三方面的測試驗證工作都完成之後，機台開發專案進入第五階段出機流程，開始展開出機程序，包括拆機﹑清洗﹑包裝﹑搬運﹑安裝﹑試機﹑試電﹑試運轉﹑上線測試﹑製程驗證與驗機。

圖一﹑機台設備廠商系列機種開發模式

圖二﹑機台開發專案執行流程簡圖

隨意壓縮時間是不智之舉

就現在的消費性市場來看，產品的世代交替時程可以說越來越短，而技術的演進與製程的更新速度也非往昔可以相比。在產品生命週期嚴重壓縮的情況之下，產品的推出速度與時機就成了企業競爭力的關鍵點。由於消費性產品生產廠商的需求快速變更，相對的新生產機台的開發時程也必須隨之配合，準時出機與縮短開發時程成為首要任務。可是機台開發專案並非如此容易執行與掌控，除了技術障礙與投入資金之外，外包交期延誤與規格臨時變更的風險隨時可能發生。因此如何在不降低品質與縮減功能的前題之下，確保機台開發專案準時完成並且進一步提升開發的效率，將是很重要的事情。然而這個目標卻不易達成，專案經理（Project Manager）得從專案開始就十分小心控制進度與預防風險，外包問題與技術障礙也必須事前評估防範與危機處理，事前的周密防範比起事後的補救好。但是以現況來說部份專案經理並沒有針對問題的根源考量與處置，往往是在時程延誤之後採用「頭痛醫頭﹑腳痛醫腳」的方案救急，其中又以隨意壓縮「軟體試機」時程的狀況最為常見。因為以專案執行的流程來看，「軟體試機」總是在專案的後半段，幾乎在出機前一階段或是前前一階段。因此在專案開發時程很緊迫的情況，或是機構設計時程延遲﹑機構加工交期延遲的時候，往往就會拿「軟體試機」的時程「開刀」。或許是因為專案經理往往是機械背景，或是對於控制軟體的概念不夠清楚，總以為「軟體試機」階段是最容易壓縮時程的部份，只要透過加班﹑功能縮減﹑降低品質（堪用即可）﹑新增人力或是先出機再試機等因應方案，就可以輕易壓縮工作時程，藉以彌補之前所延誤的時間，但是事實上這些方案都是很危險的。固然「軟體試機」效率是可以被提高﹑時程是可以被壓縮的，但是這必須透過事前周密的計畫與長期的技術累積。也就是軟體團隊的主管經由周密的規劃長期奮鬥﹑精益求精，藉由多次機台開發技術與重用模組的開發，累積「資源」與「文化」才能提升的效益。盲目的壓縮控制軟體試機時間甚至於程式設計時程絕對是一件很危險的事情，因為任何未經驗證的程式碼基本上都有其驗證所需最短時間，而任何未經驗證的程式碼都有可能在實機運轉時造成機台重大的事故。

首先我們先就上述的常用方案分別來探討問題點。(1). 加班：加班屬於非常態性工作，偶而為之是可以收到救急的效用，但是長期使用或是習以為常的話往往會造成優秀工程師的離職。(2). 功能縮減：功能縮減其實並不實際，因為機台的功能在專案規劃階段都已經規劃並經確認完成，而且大部分功能也是交機簽約的規格，或者是機台運轉的必備功能，豈是說縮減就縮減的。(3). 降低品質堪用即可：降低品質是最危險的方案，軟體中未經驗證的程式碼需要驗證的所需最短時間是很難只靠趕工就可以縮減的。而未經驗證的程式碼如果不驗證就直接使用的話，隨時可能在機台出機後造成當機﹑撞機﹑製程失誤甚至於操作人員傷亡等重大事故。因此隨意降低品質只會造成維護/客服成本增加，以及公司形像損毀。(4). 新增人力：人力的新增本應有機會加快開發時程，只是最大的問題在於專案經理的決策往往是在專案後期嚴重延誤時才決定，常會錯過可以挽救的時機。或許因為預算超支是專案經理考量的重點，除非專案延誤情況嚴重，否則不會向上層要求更多人力以致於影響考核。所以新增人力的投入總在專案後期告急之時，甚至在出機前夕，而此時機台的大部分功能都已經設計完成，新增人力在面對如此龐大且複雜的系統時，怎麼可能一下子就立刻進入狀況開始工作呢？等到熟悉系統有能力切入與協助進度時，專案或是出機時間的延誤早已成定局。(5). 先出機再試機：有時因為簽約問題，交機時間已到但是機台尚未測試完成，在客戶的默契之下或許會先出機，然後在客戶工廠內繼續測試工作。但是這是不得已的下下策，因為在客戶工廠內測機不但壓力大﹑效率低，而且由於試機時難免會當機﹑誤動作甚至撞機，這些都是試機階段必須經歷與改善的過程，對於習於開發機台的工程師來說是正常過程。但是如果被客戶員工看到，對於習於製作產品的工程師來說，有可能因此被解讀或誤認為機台穩定性與品質很差，對於公司的形象與日後新機種的銷售或許有不良的影響。而且在客戶工廠內測機往往會讓試機時間倍增，因為客戶的工廠並非開發廠商的組裝線，不管在儀器使用﹑場地空間﹑人員支援等方面，都不可能同原開發廠商組裝廠的水準與工作效率，因此驗機的時程倍延也在所難免。因此本方案或許可以滿足簽約約定的裝機時程要求，卻是能不這樣做最好不要這樣做。

所以就短期來看，如何在不降低品質與縮減功能的前題之下準時出機，以掌握瞬息萬變的市場與商機；以及就長期而言，如何能自陸續開發的機種間，累積自有技術並持續提升專案執行效率，減少機台開發所需時程與人力，這些問題的答案將是機台設備廠商的競爭力來源。因此接著我們開始就問題的根源，探討機台設備廠商開發採用PC-Base控制器新機台時，在控制系統的軟體開發方面如何提升專案執行效率，以及如何累積自有技術﹑持續改善效率與降低開發成本。

基本法則

首先，機台設備廠的開發人力必須要充足，這是達成準時出機的基本需求。雖然在某些多工作業狀況嚴重的時刻人力不一定足夠，但是平均人力充足應該是最低要求。在人力資源合理﹑相關技術無致命性障礙﹑關鍵性零組件無競爭者壟斷的前題之下，機台開發專案控制軟體開發的執行基本法則：不要成為專案執行的瓶頸，也就是成為限制理論（TOC，Theory of Constraints）中的「制約因素（constraint）」[4][5][6]。簡單來說，就是不要變成專案執行時程延誤的來源。如圖二所示，一般機台開發專案執行流程在軟體規劃階段（以下簡稱階段A），進度完成時間必須在機構規劃完成時程之後。因為部分配電規格必須等機構規格確定之後才能因應設計與確定，而部分軟體規格也必須等配電規格確定之後才能著手設計與確定。因此此時控制軟體的進度時程是掌控在機構與配電的時程上，也就是說在階段A不會因為控制軟體進度時程的延誤而造成專案的進度立刻延誤。在軟體程式設計階段（以下簡稱階段B），控制軟體開發進度與機構設計﹑組立圖﹑拆圖加工圖﹑加工與組裝等時程重疊，因此如果機構與電控的工作效率都已經最佳化且無事故延誤，那麼控制軟體AB二階段的時間總合只要比機構/電控時程短，現階段專案進度應該沒問題。但是軟體試機階段（以下簡稱階段C）則是關鍵點，因為在機台開發專案執行中，「軟體試機」是獨立的開發時程，位於專案的要徑（Critical Path）上，也就是說這段時間的長短直接影響機台上線或是出機的時程，「軟體試機」階段如果比當初預定的多一個工作天，出機時程可能就得增加一個工作天（如果其他階段沒有進度超前的話）；「軟體試機」階段如果比當初預定少一個工作天，出機時程可能就可以提早一個工作天（如果其他階段沒有進度落後的話）。所以消極面來說，階段C的工作是否能準時完工對於準時出機有決定性影響；以積極面來看，在不影響品質與功能的前提之下，如何減少階段C所需時間則是另一個值得探討的問題。因此專案執行效率的提高方案主要分二大部分：如何壓縮軟體試機（階段C）時間﹑如何降低程式規劃設計（階段A/B）的人力成本。

壓縮軟體試機（階段C）時間

如何壓縮軟體試機（階段C）時間，重點在於儘量減少階段C的工作量，並且設法讓這階段工作切割清楚以方便多人分工合作﹑同時進行。可行的方案大致有三種：能做先做﹑分割先做﹑分工同步。以下針對這些方案說明之。

1. 能做先做：首先軟體團隊主管或是專案經理要先深思，到底有哪些工作是非在階段C不能做的。原則上這些一定得在階段C才能進行的工作才能安排在階段C進行，其他的工作都得分散到階段A/B進行。或許有些工作在階段C做比較省事或比較有效率，但是並不是非得等到階段C才能進行，這類工作也不應該因為個人工作方便因素，或是人事執行成本等理由而將工作放入階段C進行，畢竟在這種產品快速變遷﹑生命週期短而競爭激烈的時代，產品上市的時機才是勝敗的關鍵。但是如何明確的劃分可以在階段C進行的工作與不可在階段C進行的工作呢？其實階段C與非階段C真正的差異點只在於有沒有實際機台可以使用。也就是說除非該項工作進行，機台是必要條件者才能安排在階段C進行，這就是所謂的「能做先做」。在機台出機（或是開始量產）之前，控制軟體程式的所有功能，每一項都要經過規劃﹑設計﹑測試﹑修改﹑驗證完成，不管這些控制程式被切割成幾項或是由多少人員負責，基本要求是不變的。因為任何未經驗證的程式絕對是bug的根源，也是公司未來聲譽受損﹑售後服務與維護成本增高的可能性原因。或許有些功能可以離線初步測試，但是無論如何實機的驗證絕對是必要的事情。因此專案經理應該於規劃階段進行控制軟體分析，針對每一項獨立工作拆解成規劃﹑設計﹑測試﹑修改與驗證五大階段，並且解析哪些項目中的哪些工作才是真正必須要在階段C才能動手進行的，哪些項目中的哪些工作是可以事先進行的，依照「能做先做」分派原則適當的安排工作。
2. 分割先做：有些工作雖說機台是必要條件，但是如果仔細分析工作內容，有時候可以將工作切割成二部分，前半部分不需要機台就可以執行；而後半部分才真正需要機台。這種狀況最好將工作切割，只將後半部份工作放到階段C進行。這就是所謂的「分割先做」。但是有時候得插入某個中繼工作可以將工作分割二半，讓前半段的必要條件變成只需要中繼工作而不需要真正的機台，那麼前半段就可以不需要安排在階段C進行，只有後半段才需要在階段C進行。例如某個機構模組的程序控制程式，未分割前程序控制程式的執行當然得有機台才可以測試﹑修改﹑驗證，否則無法程式除錯與功能驗證。但是如果我們花點成本（時間與人力）製作簡單的「機構模擬系統」，那麼該機構模組程序控制程式就會因為加入「機構模擬系統」這個中繼工作切割成二部分，前半段工作為程式規劃﹑設計﹑使用「機構模擬系統」進行模擬測試與初步除錯，這部份工作變成不需要機台而可以安排在階段A/B進行；後半段工作為使用實際機台進行實機驗證與除錯，這部份工作則安排在階段C進行。比起整個工作都得安排在階段C進行，或是直到階段C才開始進行最基本的測試﹑修改與驗證，專案執行效率會有大幅度提升。當然「機構模擬系統」這個中繼工作做的越接近實際機台，實機驗證與除錯後段工作所需的時間就會越短。可是製作中繼工作也是需要時間與人力成本，而且完成的時程安排也是一大問題。因此一味的提升「機構模擬系統」等中繼工作的功能規格並非良策，適度的在中繼工作的功能規格﹑製作成本﹑作業時程，以及階段C所能節省的時間二方面取得平衡點才能獲得最佳效率。
3. 分工同步：當機台開發專案實際進展到階段C的時候，因為此時安排的所有的工作都是與機台相關，都是非得在機台內的控制器硬體執行的工作，因此這階段的制約因素變成是機台硬體。所以如何讓機台不會閒置或是讓機台可以24小時有效運轉，就是階段C最佳化的原則。有句諺語說：九個女人也不能一個月就把孩子生出來。為何呢？因為生孩子這工作是無法切割的，所以就算九個女人一起合作也無法提高效率。因此如果階段C的工作無法切割的話，那麼也是無法透過人力的增加來提升效率。當然機台只有一台，控制器可能也只有一個，因此同時間可以進行的工作也只有一項。雖說機器可以24小時無休的讓工程師測機，但是工程師卻無法24小時無休的工作。就算拼命加班，也常會發生因為當初考量點錯誤或是邏輯錯誤而得大改程式的狀況，遇到這種狀況軟體工程師需要的是較長時間的安靜工作而不是機台，因此此時機台就會閒置，而制約因素就會轉為那位工程師。所以如果我們可以把階段C要進行的工作分工，也就是將系統分割成獨立模組與層級，由不同的工程師負責測試﹑驗證與除錯，那麼當某位工程師因為重大錯誤需要長時間修改或是改寫程式時，機台就可以讓給另一位工程師進行另一模組的測試﹑驗證與除錯。這就是所謂的「分工同步」，以充分利用機台這個制約因素。當然不可否認的這種方法可能會讓某些工程師在某些時間點閒置以等待測機，對於管理階層來說這種閒閒沒事做的狀況很礙眼，但是如果考量到準時出機的重要性，這種狀況應該可以被允許的。

降低程式規劃設計（階段A/B）的人力成本

由於軟體規劃和程式設計（階段A/B）在專案的執行安排上與機構/配電同步工作，因此此時控制系統軟體開發的效率提升重點分為二部份：首先要確保控制軟體除了需要在階段C進行的部分以外的所有工作都能在階段A/B的時限內完成；其次是在軟體品質與機台功能不降低的前提之下，如何適度的降低階段A/B所需人力。乍看之下，這二個目標看似矛盾或是零和，其實不然。以單一專案來看，又要要求人力縮減又要要求準時完工，這是典型的「既要馬兒好又要馬兒不吃草」。但是如果以公司永續經營理念來看，公司不會只開發一個機台，而是一個個機種陸續進行開發。如圖一與圖三所示，軟體團隊可能同時開發數個機種，而且同一家公司所開發的機種間不可能差異過大，因此系統的運作模式與架構必然雷同，雖然不同的機種可能由團隊中的不同工程師所負責，但是透過專案間的整合與重用，很多重複性的工作就可以節省，而類似的模組可以快速開發。此外公司對於新機種的開發是不會間斷的，當軟體團隊開發完成一個機種之後必然會有另一個機種的開發需求。因此這個機種開發的控制軟體部份模組，就可以提供下一個機種使用而不需要重新開發，如此一方面可以提升開發效率降低階段A/B所需人力；另一方面因為重用模組都是經過實機驗證的可信賴模組，因此軟體品質也會間接提升。此外，機種開發完成與下一機種開發之間，有時會有部分閒置時間或是閒置人力可以利用，如果軟體主管能善加利用這些資源，就有機會可以讓控制系統軟體開發的人力成本與所需時間持續降低。也就是當專案完成機台出機之後，除了專案所需的技術文件之外，軟體團隊也累積了對於下一個機種的開發效率提升能力。這些能力除了工程師個人的技術提升之外，還包括某些人機介面模組重用﹑硬體Driver﹑程序控制模組樣版﹑通訊模組重用與測機工具程式等等，如果可以利用專案間的閒置資源延續開發（例如選定適合的程式繼續改良增加重用性）﹑或是根據開發經驗設計程式樣版﹑或是小量修改程式成為未來試機工具，善於利用經驗精益求精，累積自有技術持續改善，這才是企業競爭力的來源。關於控制系統軟體開發如何累積自有技術，本文從三方面進行探討：共通系統架構﹑軟體模組重用﹑開發與試機輔助工具。

圖三﹑前後機種開發的技術累積

共通控制系統架構

機台設備廠商的軟體團隊如果想在機台開發間累積自有技術，首先得制訂完善的共通控制系統架構，透過具備彈性與擴充性的自有架構才有機會整合與分享。筆者在前作「共通控制程式架構」[1]，曾提出一套汎用型架構以提高軟體重用性﹑建立標準介面﹑縮短開發時間﹑提升軟體品質與增進維護效率。而在「控制程式發展系統」[2]中，則提出應用共通控制程式架構建立公司開發用系統的理論。這些架構與原則就是試圖建立一套分層清楚﹑模組化程度高的系統架構，透過適當的分層化與模組化來簡化系統，提高軟體品質。如果公司內部的軟體團隊所有開發的機種都能依照此架構與原則開發程式，不但可以提高軟體模組重用性，更可使得分工清楚而且相互支援困難度降低，甚至於當專案時程發生延誤或是因故必須加快開發時程等緊急狀況時，共通控制系統架構可以讓軟體團隊的其他人員很快的加入專案協助開發加速進行，而前後機種的技術累積效益﹑軟體模組重用性與開發樣版的建構也才有機會實施。

以PC-Base控制器來說，II Tier / IV Level（二階四層）是較佳的共通控制程式架構模式。如圖四所示，控制軟體系統分為「控制核心」與「人機介面」二階，而「控制核心」又分為「硬體驅動層」﹑「程序控制層」﹑「系統排程層」三層，這三層與「人機介面」總共四層的架構。每一層都是由數支函數（或物件）與執行緒所組成的，層與層之間定義標準介面（Level Interface）互相交換命令與資料。上層程式透過標準介面下達命令給下層程式執行；而下層程式的執行結果或是執行狀態，也透過標準介面上傳處理﹑儲存或是顯示在人機介面。系統架構分層負責層層封包的設計，可以建構高度模組化的控制系統軟體，以降低出錯的風險﹑增加修改/擴充的彈性﹑減少因增修而意外出錯的機會[3]。以下針對各層的功能與設計說明之：

「硬體驅動層」：硬體控制卡的抽象化。控制器中實際控制外界動力源或讀取狀態/資料的是硬體控制卡，種類繁多有很多廠牌與型號可供選配，但是使用方法卻不大相同，例如不同廠牌的運動控制卡（Motion Card）所提供的功能或許是大同小異，使用介面與方法卻沒有統一的標準。因此如果讓上下層程式都直接控制硬體控制卡，當硬體控制卡因故更換時就會造成程式修改的困擾。同時這種作法也會導致程式架構不夠模組化，造成維護困難與重用性降低。建議針對每一種硬體控制介面卡設計一組Device Driver，並且制訂硬體驅動層標準介面（Driver Interface）定義標準命令與回應規格，然後讓所有同類型硬體控制卡的Device Driver遵循硬體驅動層標準介面，以及該類型Device Driver汎用介面參數。如此上層程式（硬體驅動層以上）的規劃與設計就不需要考慮個別機台所選用的硬體廠牌與型號，只要遵循硬體驅動層標準介面與該類型Device Driver汎用介面參數，就可以控制硬體輸出/輸入。如果機台規格臨時變更而導致硬體控制卡需要更換時，僅需抽換Device Driver即可，可以降低專案規格變更所產生的時程延誤，並且提高軟體品質。

「程序控制層」：將機構的動作流程抽象化，機台機構動作流程程序控制。程序控制層擁有程序控制層標準介面（Function Interface）提供給上層程式使用，讓系統排程層的排程派工程式或人機介面階層的人機介面程式，能下達命令給程序控制模組程式。當程序控制模組程式接受命令之後，根據該模組所設計的動作順序，依次下達命令給硬體驅動層，透過Device Driver真正輸出控制動力源運轉；運轉結果先由Device Driver讀回，透過Driver Interface回應給原程序控制模組程式處理。程序控制部份可以採用多執行緒（multi-thread）以程式語言撰寫，例如使用Visual C++或BCB。這種方式彈性高﹑功能強而且由於採編譯為機器碼方式，執行效能很高。但是由於程式設計方法過於自由，後續維護﹑人員流動與交機工作的交接有時會發生困難，程式品質也會因人而異，因此建議製訂程式樣版以降低維護成本，並提高重用性。另一種方案是採用直譯器與描述語言，例如設計一組專為程序控制的描述語言（例如筆者的FSP[1]），提供設計程序控制的工程師使用以撰寫程式，然後開發一套直譯器核心提供類似虛擬機器（Virtual Machine）模式載入並執行該程序控制描述語言的程式，對外介面依然採用共通控制程式架構所定義的標準介面。這個方案最大的優點在於直譯器核心在軟體試機階段（階段C）可以提供較佳的除錯與記錄功能，並且由於程序控制描述語言的困難度與進入門檻較低，因此電控工程師也可以協助開發，以降低軟體工程師的工作量；或是在專案延誤或突發性的時程緊縮時，可以快速的分工以加速開發工作。

「系統排程層」：排程派工負責協調機台各獨立模組共同運轉。大致來看區分為二種模式（Mode）：手動單功能運轉（Manual Mode）﹑全自動運轉（Autorun Mode）。基本上，排程派工的程式機種間的差異性很大，原始碼很難重用而且模組也很難切割。但是如果放任工程師依照個人主觀喜好自由撰寫程式的話，一方面程式品質很難掌控；另一方面維護與交接的困難度也會提高，因此建議制訂程式樣版與標準設計法則，將程式碼標準化。

「人機介面」：擔任控制系統的操作人員介面與操作流程。主要功能區分為四項：(1). 機台參數（Parameter）的編輯﹑顯示﹑儲存﹑修改﹑刪除功能（例如：機台狀態-燈號表﹑Arm設定）；以及物料參數的選取﹑編輯﹑顯示﹑儲存﹑修改﹑刪除功能（例如：Tray長寬值﹑加熱溫度與時間）。(2). 生產狀況資料的顯示﹑儲存功能，包括工程資料與製程資料。工程資料包括生產管理的資料（例如：產能﹑生產時間）以及機台運轉資料（例如：Alarm歷史資料﹑Log資料﹑MTBF故障發生平均時間﹑Up-Time﹑Down-Time﹑UPH），可以提供生管/維護工程師參考；而製程資料主要是物料製程中所使用或是所發生的物理量值，這些數值有些在機台運轉過程中就被即時分析與預警（例如SPC），有些則透過資料庫儲存供品保/製程工程師分析參考。(3). 機台單功能測試（Manual Mode）：維護工程師直接控制程序控制層做單步或單功能運轉。(4). 機台全自動運轉（Autorun Mode）：作業員全自動運轉機台，並於運轉期間隨時回報各項生產資料。提供作業員管理機台﹑上下料或是確保機台的正常運轉。基本上，人機介面程式龐大複雜而且機種間的差異性大，很難設計一種共通人機介面模組以因應各種新機種的開發。但是如果適當的分割，則部份模組可以事先設計與重用，部份模組可以制訂樣版以提高品質降低維護成本，剩下的才是需要依機種不同個案處理的。

圖四﹑共通控制程式架構

軟體模組重用

當機台設備廠的新機台開發團隊制訂與執行共通控制系統架構之後，幾次的開發專案經驗就可以讓團隊成員累積了不少的經驗與技術。此時軟體主管就應該開始著手進行共用核心與軟體模組重用的規劃與執行。假設機台控制程式的開發都是依「二階四層共通控制程式架構」所建構的，那麼機種間程式碼大概有60%至80%都是相同的，因此將前後機種的控制程式共通部份抽離出來就可以建構開發團隊的「控制程式共用核心」。，然後將機種間因應規格與動作流程不同的部份獨立開來。如此後續新機種的開發就不用一切從頭開始，而可以直接使用核心程式，再針對機種不同部份予以開發與修改。例如核心程式為父Class，各機種繼承與修改之。或是將核心程式編譯為DLL，各機種程式可以使用該DLL開發。如此可以有效的降低開發成本與時程，而且因為核心程式與因機種間不同而個別開發的程式分離，在除錯﹑維護與版本更新上會更快速。

「控制程式共用核心」大部分屬於二階四層中的「控制核心」。因為「控制核心」的程式樣式比較固定，可以共用的共通程式比率比較高，可以抽離的共用核心比較完整，而且因應機種間的不同的客製化程式碼也比較容易分離。「人機介面」階層部份，程式模組的重用與標準物件庫（函式庫）的建構，同樣的對於以後的新機種開發效率與品質提升也相當重要。但是機台人機介面的特質是不同機種間的差異性極大，或許因為人機介面的好壞主觀意識與喜好佔很高的比例，不同廠商所偏好的操作介面都不大相同。就過去的經驗來說，人機介面客製化的需求不僅僅是機種與機種之間不同而已，同機型賣給不同的廠商也常會因為種種因素而被要求修改，甚至於同機型前後交期機台因為對方的工程師人事調動而更換時，也曾被要求修改。例如同一種機型賣給A廠商的不同生產線，雖然在同一家公司，也會因為「降低教育訓練」﹑「操作方式統一」等等主觀意識而被要求修改(但是面對國外機台，國內廠商就不會如此要求)。因此乍看之下，可重用性很低也很難設計出共通核心或萬用程式。似乎人機介面開發時程的縮減除了因為工程師的經驗與技術增長所提升的效率外，就無法更進一步降低開發成本了。其實這是就整組人機介面程式來看，如果仔細研究人機界面程式並從單一功能面來看，各機種間的共通性與可重用模組基本上還是存在的。人機界面程式大致上可分為四大類，以下分別探討之。

1. 開發與組裝用工具人機界面：設備廠工程師為了開發﹑測試﹑組裝與調整等工具。這類工具大致上有：I/O設定與測試﹑伺服馬達的設定與測試﹑機構的重現性測試﹑機構Patch Error補償量測……等等。工具的人機界面功能﹑擺置位置﹑顏色與操作流程，通常客戶不需使用。因此建議開發成一個個獨立的應用程式(執行檔)，並且將機種間差異以外部文字檔案格式（或是INI﹑XML格式）設定，以降低重覆程式撰寫成本﹑減少新機種開發時程並提高裝機﹑配電與測機品質。如此一來就算人機界面﹑排程派工與程序控制等部份程式都尚未完成的時候，機構組裝與配電工程師也可以不需要程式設計師在場就可以獨立組裝與試機，並完成機台第一階段測試。而且由於工具都是圖型人機界面的獨立應用程式，全廠統一並且針對該公司的需求與作業流程所開發的，因此提高了組裝﹑測試與裝機調整的工作效率，降低教育訓練的成本，並且由於使用技術門檻低，用人成本也就可以因而降低。
2. 工程師維護用工具人機界面：使用者為設備廠工程師與客戶端設備工程師(或是維護工程師)；主要功能是設定模組基本組態﹑模組教點﹑測試模組功能等工具。這些工具是因為機種間的微小差異需要教點與微調；或是程序控制開始測試前的模組基本功能設定與測試；或是裝機時校正；或是保養時單模組動作與基本組態變更。這類工具客戶雖會使用到但是頻率不高，而且使用者多數為職級與教育程度較好的工程師，因此絕大多數的狀況是不會有意見要求修改。建議事先設計完成或是延用前一機種的元件，並且全廠統一以節省人力與物力。
3. 系統管理與查詢工具：系統管理用工具，主要提供客戶設備工程師使用，包括新增作業員的ID / Password﹑設定作業員權限﹑機台故障記錄查詢﹑機台運作狀態監看﹑機台故障歷史資料查詢與統計圖表，甚至於機台自動診斷等。雖然這類工具與客戶切身相關，而且使用頻率也高，但是由於功能專業性高且使用者教育程度好，通常客戶不會因為主觀的喜好隨便要求修改，建議模組化以提高重用性。然而這類功能是屬於系統管理，隨著機台規格不同而有很大的差異，若想設計成重用元件與標準介面則得先標準化機台的架構與流程。
4. 作業員操作機台用人機界面：這是比較難設計重用元件的部分，建議以功能為單位寫成一系列元件庫（物件庫），以原始碼型式提供後續機種開發工程師重用。透過以上這些重用元件的排列組合與修改，就可以完成80%的人機介面程式，至於剩餘的部份因為大部份是屬於機台操作流程設計，而操作流程的程式碼對於機台的不同差異性過大，必須被個別考量重新撰寫，可以重用或是事先設計的可能性很低，但是為了後續維護與軟體品質的確保，建議制訂標準撰寫樣版與規範。

開發與試機輔助工具

另外為了因應試機需求，以長期的角度來看有必要適時的開發「試機工具組」。大致來看所需工具有：機構工程師測試機構重現性工具程式﹑螺桿patch error補償時雷射干涉儀量測用工具組；配電工程師用的接點測試工具軟體﹑I/O測試工具軟體﹑A/D測試工具軟體﹑D/A測試工具軟體﹑伺服軸測試工具軟體﹑伺服軸PID調整輔助工具軟體﹑溫控模組測試工具軟體…等等；以及軟體工程師試機﹑驗證與Debug工具軟體，包括簡單的機構模擬工具﹑Log分析工具…等等；以及出機後裝機﹑調機或維修保養時的相關參數調整輔助工具軟體。這些開發與試機的輔助工具組最好能於專案間的閒置時段事先規劃與設計，除非不得已儘量不佔用機台開發專案的執行時間。執行的要點首先先確定公司內各種機台，所有會使用到的各類PC Base控制卡的型號。例如I/O控制卡選定某廠牌的某二種型號，伺服馬達運動控制卡也依需求選定幾種型號，不管那一種機台除非逼不得已都得採用這些選定型號中的硬體。然後針對配電﹑設定﹑試機﹑Debug與維護等五項需求，設計相關的「開發與試機輔助工具組」。工具的設計考量重點不在於畫面的美觀或是高超的程式技巧，而是完全著眼於生產現場的實際需求與操作習慣。

結  語

控制系統的開發所需的技術表面上與IT技術極為相似，但是卻有著截然不同的特質。而且相較於IT技術的日新月異，控制系統卻鮮有深入的探討。然而隨著機台的日益複雜化，所需的技術也不斷增加，如果設備商無法透過機種的陸續開發持續的累積自有技術，並且提升開發效率與軟體品質的話，企業的競爭力絕對會逐漸減弱。也就是如果每次新機種的開發都得「重新發明輪子」，而開發工作者又都抱著「堪用即可」的觀念的話，長此以往公司必然有危機。本文中所建議的方案在不同廠商﹑不同機型﹑不同管理文化與不同系統架構，實施的細節雖然不盡相同，但是基本原則與概念是不變的。

參考文獻

[1]曹永誠，共通控制程式架構，電機月刊第99期，1999/3
[2]曹永誠，控制程式發展系統，電機月刊第140期，2002/8
[3]曹永誠，漫談PC-Base控制程式設計(1)(2)(3)，工業電機&自動控制裝置與設計雜誌，1998/7,8,9
[4]高德拉特，目標－簡單而有效的常識管理，天下文化，2002/6/30
[5]高德拉特，絕不是靠運氣，天下文化，2002/6/30
[6]高德拉特，關鍵鏈－突破專案管理的瓶頸，天下文化，2002/6/20