labview中开发中大型软件的一种架构的研究[转帖] 架构, labview, 软件, 转帖, 开发

chenchao8848

通常一個VI若包含三、四十個以上的subVI(不包含LabVIEW本身在Functions中提供的VI)時，就可算是一個中大型的軟體計劃(software project)了。雖然比起軟體工程中的一些作業環境軟體(如Windows系列)或大型應用軟體(如Word、Excel)等仍算是小工程，但其複雜性亦在一定程度之上，若沒有事先想好在撰寫程式時的一些規劃與方法，想要完成這類中大型的軟體絕對不是一件簡單的事。尤其這類軟體通常不是由一個人，而是由一個團隊所共同完成的，因此整個軟體的結構，就要能讓團隊中的每一成員都能清楚的了解，而且要夠簡單，才算是好的軟體結構。以下將參考由Rick Bitter等人所著”LabVIEW Advanced rogramming Techniques”，中之第4章的部分內容，介紹所謂軟體計劃中的三層式結構(the Three-Tiered Structure)的概念及其優點。 fficeffice" />

   需要軟體結構的主要原因，是當軟體人員發展軟體到某一階段時，若沒有計劃或無意的創造了許多subVI，但各subVI之間有許多部分其實是重複撰寫的；或各VI相互間呼叫時沒有一定的紀律，使得在VI Hierarchy中所看到的各VI間的連線是錯綜複雜，像個盤絲洞一般，這將可能會使多人發展的軟體計劃增加所耗費的時間和可能出錯的機會、減低程式的效率，以及增加debugging時的困難。為了改善上述的情形，所以要提倡三層式結構的概念。

   三層式結構由上而下依次為：Main Level、Test Level和Driver Level，這種結構是由經驗中得來的，在多人發展的軟體計劃中顯得簡單明瞭，當大家都能遵照這個結構來寫程式時，這種結構就可以充分顯現出它的優點。那這三個階層到底如何區別呢？以通俗的比喻來說，假設我們如果要組織一個籃球隊參加全國比賽，每個球員要練習基本動作及體能，如何跑、如何跳、手腳該如何放置才是正確位置等，這就相當於系統中Driver Level所做的事情；接下來，將各球員組合練習某一套防守或進攻的戰術，如二三區域聯防、人盯人防守，每個人該在什麼位置才能正確接應等，則像是Test Level中一項項的test了；而最後比賽時，場上的戰略運用，包括何時要用什麼戰術組合、如何更換球員、何時喊暫停、終場前是不是要故意犯規或採拖延戰術等等，對照過來，就像是在Main Level中，如何將Test Level中各test做最有效能的整合與排列組合等的工作。

簡單來說，Driver Level包含了程式與所有儀器、元件、馬達或其它應用軟體的溝通、控制等較低階的事情，使其可完成某一項基本的動作，例如初始化、馬達走到home位置、雷射以設定的能量及頻率發射光束‧‧‧等。可注意到我們在這邊所說的driver，並不像一般在別處所稱驅動程式的那種driver那麼低階，真正最低階的工作還是要有現成的VI來幫忙才行；在Test Level中，則是如何連接各個Driver VI的基本動作，使可做完出一套連續、有意義的流程，來執行某項測試，例如讓手臂由A點走到B點，下降夾取一個螺絲，再走至C點裝到某面板上，然後回到A點等待，類似這樣控制一個流程的進行，便是Test VI的工作內容；Main Level則包含了使用者介面(User Interface)或稱人機介面(Man-Machine Interface) ，目的是整合各項測試和例外處理(Exception Handling)等，將它們以適當的順序及流程組合，很容易地讓使用者操作。

當一個軟體計劃嚴格的遵照上述的三層結構來撰寫時，最大的優點是可使程式碼的再使用(code reuse)達到最大化，在不同的Test VI中，可重複使用相同的Driver VI；而在不同程式的Main Level中，又可重複使用相同的Test VI，這將使得程式維護或修改的時間與精力大幅減少；同時當我們已有一個程式的樣板(template)後，可增加軟體版本更新的速度。另一個很重要的好處是，當我們在撰寫某一個level中的程式時，並不需要關心在另一個level中有什麼其它的程式是如何執行的，而只要專注在自己的這個level的程式上就可以了，這使得由團隊來共同完成一個大型計劃的工作變得容易許多。

   以下將依Driver Level、Test Level、Main Level的順序，來介紹在各level寫程式時的原則與心得﹔(1)  Driver Level﹔通常在Driver Level所寫的程式是比較低階的，其功能是把一些最基本的I/O動作按某一順序連接起來，形成基本動作，大致分為三大類﹔a.  組態(configuration)：開啟或關閉與儀器的連結、將儀器初始化及設定組態等。b.  量測(measurement)：由儀器讀出測量值或特定的資料。c.  動作／狀態(action/status)：一個流程的啟始或結束動作、檢查錯誤等。

簡單來講，Driver Level的內容是藉由一些介面(卡)，經digital I/O或analog I/O由儀器取得上一些sensor的電壓值，或傳出一些電壓值來控制機器、儀器或馬達等的組態與動作，使得儀器或機器能夠正確設定及做出一些基本的動作。另外程式與儀器間的資料傳遞或在自身電腦的存取動作，規定檔案的格式以及存取等等，也都屬於Driver Level中應該完成的事項。但是真正最低階的工作還是需要NI提供的VI來進行，我們所寫的Driver VI仍是屬於較高階的。

 

chenchao8848

以下舉一個利用7344卡來控制馬達動作，而使BM7移動的Driver VI實例﹔
首先要確定馬達所有的動作有哪些，我們可簡單分類如下﹔初始設定、找尋Home點、移到指定位置、以及回報現在位置等。當然我們必須先在MAX上做細部的設定，接下來再回到LabVIEW中來撰寫Driver VI。看起來我們必須寫四個Driver VI來控制馬達，但這樣往往造成subVI過多的情形，因此我的建議是將關於同一個儀器或裝置的Driver VI合併為一個。合併的方法為利用一個enumerated type的control加上case結構即可。完成後如下圖﹔
利用名為Action的enum control來控制此Driver VI要進行何項動作。記得在編輯icon時，要將此enum control加到input terminal即可。
在Test Level中呼叫時的方法就可如下圖所示了﹔
如此一來，我們便可以利用一個subVI來完成數個動作了，減少了一些管理subVI的辛苦。但請注意，這樣的Driver VI要看情形而在其File> VI Properties…> Execution中設定為reentrant，因它很有可能同時被數個Test VI呼叫。
在大型程式計劃發展時，一個觀念很重要：Driver Level中的VI是整個軟體計劃中最重要的部分，它們的好壞直接決定了這個軟體計劃的成功與否和完成後的品質，就像要蓋高樓大廈，打地基、灌水泥以及基本用料的好壞才是決定建築物好壞最重要的地方，若基礎的部分不好，無論大樓外觀有多雄偉或多漂亮，假使地震一來，都有可能會倒塌。Driver VI若不先規劃，往往會造成程式效率減低，以及重複的程式碼過多等現象。雖然在最後主程式執行時並看不到Driver VI，但它們可是最重要的無名英雄，所以在設計Driver VI時需要多費點心思喔！

chenchao8848

(2) Test Level：在Test Level中的VI此處暫稱為Test VI，它可以呼叫Driver Level的VI，但只能被Main Level中的VI呼叫。有一個不成文的規定：Test VI間不可以互相呼叫；否則會使三層結構又被破壞了。可是在寫程式時，有時又覺得難以避免，或為了圖方便想說就暫時先呼叫一下吧，若有這情形發生，那就要請重新檢視一下Driver Level中的VI，是否要重寫某些部分或在寫一些新的Driver VI，以避免上述的情形發生。
有一個重要的原則，一個Test VI內只要安排一套完整的測試即可，不要在同一個Test VI中去完成兩個(以上)的測試，否則未來若整個計劃要作修改時，Test VI可能就又要修改了。一個完整的Test VI當然要包含對儀器設備的初始化，組態設定等，它是一個可以單獨執行的VI，也就是說，即使此Test VI不放到Main Level之下，它也一樣可以單獨執行來完成一項測試。另一個重要觀念是，各個Test VI間是不要有什麼關聯的，因為當在Main Level中的某個Test VI執行時，它並不確定前一個Test VI結束時的機器狀態是否合於要求，因此要重新設定，或是要重新檢查一下，以避免不能執行或有預料外的狀況發生。流程圖對於我們來撰寫Test Level中的VI是特別有用，因流程圖的概念也正好就是LabVIEW中所謂data flow的概念，因此當一項測試的流程圖清楚的畫出來並能解釋其流程時，即使我們還沒有開始寫程式，我們幾乎可以說這個Test VI的程式設計已完成60%以上了，這一點也不誇張，因剩下的部分只是將流程圖中各方塊的連接，換成LabVIEW中各function VI或Driver VI的連接而已。

chenchao8848

(3) Main Level：Main Level又稱人機介面(Man-Machine Interface, MMI)，設計Main Level程式的中心觀念是不僅要能完成測試外，而且操作上要越能user-friendly越好，因為當使用者在操作儀器設備時，他其實並不見得很關心細節的部分是如何運作的，他或許只希望能很輕鬆愉快的盡快完成工作，然後輕鬆愉快的下班回家。例如，使用者希望手臂能夠走到某特定位置去夾取一個螺絲，最好是按下某個螢幕上的按鈕就好了，只要看著螢幕上一切正常的訊息，說不定他還可以有時間悠閒地喝杯咖啡呢！通常Main Level VI的設計往往利用while迴圈不斷的polling，大部分的時候也不只一個while迴圈。其內容要包含幾個重點：a) 可讓操作者設定或更改操作參數：例如可選擇何項測試及執行順序、介面的位址、檔案的路徑等等，但也請注意，需設定的選項並非越多越好，太多的選項容易使人分散注意力而容易出錯。b) 在特定的情況下使用適當的Control：有時Control需加些心思來點變化，以表示其不同的重要性，最簡單的當然是以大小、顏色來區別，當然在執行時也可利用property node中閃爍的效果來強調，不過一般而言，常用的重要Control通常用按鈕放在Front Panel上顯眼的地方；而較不常用的Control，通常利用放在cluster或tab control中，利用invisible的功能或換至其他頁面使其平常不出現在Front Panel上。較不常用的按鈕，也較不用按鈕的形式，而可在Controls> Classic Controls> Boolean中選擇Radio Button或Checkbox來使用。請記得一個原則，在Front Panel上可看見的Control越少越好，因出現越多的Control，設定的參數就越有可能因不小心而改變，進而造成錯誤發生，要避免這種情形，可將Control連上另一Indicator後，在將Indicator放到Front Panel顯示其值即可。c) 要將眾多的Control及Indicator依使用功能分類，並適當地利用頁面切換來顯示。d) 在執行程式時可以選擇cancel或abort：這對操作者而言是十分重要的，但卻容易被程式設計者所忽視，因程式設計者會不經意的假設操作者是非常了解他所寫的程式，又非常熟練，而且一定照正確步驟不會按錯按鍵。但實際上操作者可能並不熟練或很粗心等等，有時若一旦按下某個按鈕就不能後悔的話，很容易造成萬劫不復的悲劇。請注意，程式設計者一定要在程式中加入在執行中跳出程式的方法，而盡量避免由操作者去按下toolbar上的abort(紅色圓形按鈕)來跳出程式。e) 在Front Panel上多使用圖形，避免過多的文字或數據。f) 在Main Level中統一處理所有的exception massage：這部分在程式設計中又稱exception handling，在軟體工程上也是需要專門課程來討論的，同時，這部分對於產品的商品化是非常重要的，在此只先簡單敘述，之後會有專門的專題來討論。
先談建立exception handling機制的好處：它可告知操作者哪裡有出錯，或需要注意，使不是十分熟練的新手操作者，減低發生狀況的機會；也方便製造廠商與程式設計者容易做除錯及故障排除的動作，使得整個系統的開發及維護能較有效且所短時間。
我們希望exception handling可達到下列幾個功能：當測試過程有錯誤狀況發生時，程式可以自動修復錯誤，並繼續完成測試或重新測試一次；或當測試過程有錯誤狀況發生，且此錯誤不能修復時，程式能自動跳過有問題的部分，並繼續完成測試；或測試過程有錯誤狀況發生時，程式會將整個系統暫停或終結，並告知操作者錯誤發生處。上面敘述起來似乎很簡單，但實際上它需要程式設計者看到實際操作後的結果，再一項一項加到整個程式中，然後再故意發生錯誤來測試，也因為如此，它可算是整個軟體計劃發展過程中非常耗時耗力的一部分。
若藉用前述所提過的State Machine的寫法，會使得exception handling的程式設計較為簡單，因State Machine中原本就有安排一個error state，可讓程式設計者在那裡統一撰寫處理各種exception/error message，然後在error state中判斷，是回到原來的測試中，或是走到close state去結束此項測試。因此是強烈推薦採用State Machine的寫法。
以上簡單敘述了三層式軟體結構的設計概念，及各個level中所應要包含的重點，這邊再寫一些個人的實戰心得：三層式結構它是一個原則，並非一個絕對的規定，但千萬要了解他的精神所自，它的精神是：各個VI是屬於那一個level要區分清楚，同一個level間的VI不要互相呼叫，程式的code reuse要最大化。這樣一來，當你要維護或修改這個軟體時就會比較容易了；同時，就算有團隊中的成員突然插入修改的工作也能很快了解整個架構而上手。