Posted on 2008-05-21 20:39
xlz 閱讀(472)
評論(0) 編輯 收藏 引用
作者博客：http://hi.baidu.com/xiazhifei 。如要轉載，請保持原文完整性,最好把這句話也加上。
我對ATE的理解
本來我是想寫成論文格式的，但查閱了不少別人的論文，發現我的想法大部分沒什么新意，即使寫了，也只能叫做低級重復，有點新意的那一部分呢，還沒得到證
實，充其量只能叫做設想，達不到我想象中的論文要求。寫成這種類似帖子的格式，目的也是一樣的，就是告之后來人一些經驗，提供點參考，但就可以不那么嚴
謹，可以發揮的余地就比較大了，而且本人更加喜歡這種文章的風格。
本文所寫的是我對ATE的理解，重點包含對ATLAS語言的理解，所寫的是個人看法，如要比較嚴謹的解釋，可以參照相關論文。
對ATE的整體看法
ATE就是自動測試設備的英文首字母的縮寫，我們為什么要生產ATE設備，顯而易見，為了省事，省得人工去測試。但自動測試設備要能完成人所能完成的功
能，就要有類似人的傳感器代替人的各種感覺器官，有執行機構代替人手來操作被測產品，有固化的程序之類的代替人的思維。當然這些傳感器、執行機構可以做得
比人更為精確、迅速，程序也可以做成那樣，但靈活性就不如人了，遇到特殊情況也不行了。其實不管什么東西，都是信號輸入，經過處理，再輸出的，至于如何實
現每一步的，我估計隨便一個細節都可以成為一門學科的，下文會給出稍微詳細的解釋的。
我對傳感器的看法
言歸正傳，傳感器一般有測量電壓、電流、溫度、濕度、功率等等，當今社會，一般人能想到的基本上也應該能做到了，我們做的只不過要挑選適合自己的。速度、
精度、價格、壽命、可操作性等都是要考慮的因素，使用起來也是千差萬別，但這種產品會越來越容易操作，生產廠家一般都會給出詳細使用說明，我們只要做好外
部接口，依葫蘆畫瓢就可以了。當然我也見過要用諸如單片機發送特殊格式的命令字才能工作的傳感器，但操作起來也是依葫蘆畫瓢就可以了。得到的數據也是千差
萬別，常見的是電壓和特定格式的編碼，照者DEMO做就可以了。
我對執行機構的看法
如果說傳感器有一千種，那執行機構就有一萬種了。但用起來也不難，也是依葫蘆畫瓢就可以了。一般有產生電壓、電流的，當然也有帶動某個輪子呼呼轉的，有簡
單的也有復雜的，要操作起來也是有方便的也有麻煩的。但歸根結底是不怎么要去自己想一種新的方法去使用的，和傳感器一樣，最多是照者DEMO做就可以了。
解釋以下我所說的DEMO就是類似一種例子程序，使用起來一般只要修改修改參數就可以了，要變化的話也只是把幾個DEMO修改后一起做，那都是算復雜的了。
我對程序的看法
程序這一塊就相對靈活得多了，當然有現成的DEMO可以照抄是最好的，但DEMO不可能有那么多，也不可能像如傳感器、執行機構的DEMO那樣可以基本窮
盡所有具體用法。有人說執行的語句就那么幾種，怎么不能窮盡，我說英文字母也就才26個。也許我接觸的軟件不算太多，我的理解就是程序就是語法加算法（這
句話其實是一位計算機史上的泰斗說的）。語法很容易，就曾經有人號稱兩天學會了JAVA，這我是相信的，語法也就那么多固定的語句，ATLAS據說是最復
雜的語言之一，但不也就那一兩千個單詞，常用的也就一百個吧。算法才是本質，就像你要寫本書，沒準你認識的字比魯迅還多，但寫出來的文章能夠比他好嗎？程
序的算法好象是可以申請知識產權的，道理我也就不多說了。
算法得表示出來，大家認同，共同研究的算法才是能夠得到發展的，但表示的格式可以不拘一格的，程序員之間甚至就可以寫一個DEMO就可以表示他的思想了。
但對大部分人來說，雖然算法最終要用程序來實現，但他不懂程序，或還沒能達到用程序的思維去思考程序（說得有點懸乎了，但可參考老師常說的用英文的思考方
式去讀英文，不要老想著把它翻譯成中文后再理解這句話），怎么辦，我們可以用信號流圖，框圖等來表示，本質上這些還是程序（第四代語言好象就往這方面靠
攏），但只要看那么幾分鐘就會明白，因為不管是信號流圖還是框圖，只有順序、分支、循環還有一個用得很少的跳轉這幾種形式。
有人說這每一句我都看得懂，但這一段就不明白了。每一句都看得懂電腦也能啊，要人干什么，我認為這才是人的用武之地。看這個首先要“斷句”，分成一塊一塊
的，有不少塊還是重復的，可一略而過，重點要分析的就要重點分析（廢話，但很有用）。這也是一個靠經驗的活，見多識廣在這里是真理。各人分析的方法不一
樣，可由下而上，可由上而下，也可兩者結合。我喜歡由上而下，一般的程序用它也就足夠了。總體把握了，就知道每一步是在干什么，要怎么干，當然由下而上也
有它的好處，當然要應時應勢而變。有人說這每一小段我都知道要干什么，具體到ATLAS語言就是這一小段是測啥測啥的，夠了，不識廬山真面目，只源身在此
山中，除了看懂每一段，還要整理出來，再進行分析，就高了一個層次，具體怎么辦，涉及商業秘密和知識產權，就是不說。我現在就是在干這個，雖然有不少進
展，但沒完全弄清楚，發言權就不多了，當然其它方法我還沒試過。
我對ATLAS的看法
前面那些分析是做鋪墊的，下面的才是本人查遍萬方、維普，外帶IEEE，嘔心瀝血一兩個月來得出的“一家之言”。如有錯誤，請及時告之，不勝感激！
和所有語言一樣，開始我還以為它有多艱深，還是主席說得好，戰略上要藐視敵人。
先COPY一段簡介：ATLAS作為國際通用的自動測試語言 ，應用在航空領域是航空電子系統簡略測試語言(Abbreviated Test
Language for Avionics Systems)的英文縮寫；在其它領域，則是所有系統簡略測試語言(Abbreviated Test
language for All Systems)的英文縮寫。ATLAS廣泛應用于國際軍用和民用ATE中。ATLAS作為標準的
TPS程序語言，當初是基于
FORTRAN語言制定的，但經過幾十年的發展演變，如今更趨近于C語言。ATLAS測試程序是ATE TPS的重要組成部分，通用 ATE
成功與否也就在于其擁有的TPS數量的多寡程度。分析研究
ATLAS測試程序的結構，對編寫出好的測試程序極為重要，也可以知道如何根據已有的ATLAS程序來自己做個達到其功能的ATE，除了不受制于人外，還
能省不少$呢。
ATLAS測試規范和
ATLAS測試程序是有些區別的，再COPY一段：ATLAS語言是一種用于測試的人機通訊的高級語言，是面向UUT而與測試設備無關的信號描述語言，沒
有提供特定測試系統執行測試程序所需的全部細節。ATLAS測試規范只說明與UUT相關的測試需求，因而，要在ATE上執行測試規范，需要增添一些必要的
細節，包括對ATE的說明和它的資源、限制條件以及UUT接口情況。這個處理工作通常由ATLAS編譯器或解釋器來完成，它用測試系統規定的信息，將
ATLAS轉換成可執行程序。（補充一點，這種編譯器對于你現有的硬件條件也未必適用，而且D版的也要￥1000，小弟只想FREE，誰有D版的
PAWS，告訴我，我會感激涕淋的，EMAIL:xiazhifei@yahoo.com.cn。）因此，ATLAS測試規范和
ATLAS測試過程與測試設備是相互獨立的，而ATLAS測試程序才與某種測試系統有關聯。測試規范只有在考慮了測試設備的限制條件、編譯器如何工作和儀
表精度等因素后，才能將其轉化為測試程序。因此，某個UUT的ATLAS測試規范，指的是UUT獨立于測試設備的測試需求。ATLAS測試程序是在具體的
ATE上執行該 UUT的測試規范。但住
ATLAS標準文本或日常使中，總是“程序(Program)來指“規范”(Specification)、“過程”(Procedure)或“需求”
(Requirement)，遇到“ATLA測試程序”一詞時，須注意區分其內涵。航空電子 CMM
手冊中提供的ATLAS文件，通常是ATLAS測試規范或 ATLAS測試過程。
要寫的比較多，改天繼續寫。
我對ATE的一些看法
在整體看法那一段是我個人看法，以下是一篇論文中的看法：典型的ATE系統中有如下幾類組件：開關，矩陣和標準儀器，前兩類為連接裝置，用于在UUT與儀器間建立通路，標準儀器我就不多說了，可以相當于傳感器，也可以是執行機構。
也有這樣的看法，把ATE可以細分：測試控制器、激勵資源、檢測資源、開關系統與信號接口裝置。測試控制器實現自動測試系統中各種激勵資源、檢測資源和開
關系統的自動配置，并決定其工作方式、狀態、功能和參數，控制測試信號的通道選擇與切換。測試系統與被測單元的信號交聯則是通過信號接口裝置實現。
我對開發ATE的看法
這方面經驗不多，只好借鑒別人的經驗，以下只是眾多方法中的一種：
①需求分析。對每個UUT的測試過程進行分析，得出所有的UUT對自動測試系統的全部需求，即需要自動測試系統提供的資源，包括設備能力、開關能力，根據這些需求進行 自動測試系統設計，這是整個ATE設計的基礎和目標 ；
②ATE系統設計。根據需求分析，系統設計規定了ATE需要的設備能力、開關能力、各部分的接口關系等，這是下面步驟的基礎和目標；
③ATE硬件構形。硬件設計規范必須采用國際上先進的、成熟的工業標準，以保證功能模塊的兼容性，根據需求分析構形 ATE 硬件平臺，目前ATE硬件構形主要是VXI、PXI、PCI、GPIB等標準化接口的構形方式 ；
④設備數據庫開發。設備數據庫提供ATE測試程序設備服務的能力，根據上述的系統設計來開發測試系統中設備的驅動程序，使設備能夠滿足上述需求；
⑤開關數據庫開發。開關數據庫提供ATE為測試程序開關服務的能力，根據上述的系統設計來開發測試系統中開關的驅動程序，使開關能夠滿足上述需求；
⑥使用 ATLAS語言開發每個UUT的測試程序。
其中后面3步可以并行開發。
這中間比較基礎的是需求分析，開始一定要弄正確，至少要越正確越好，要不然謬之毫厘，失之千里。對于軟件工程的話，可能這是最重要的，但ATE的需求分析
相對應簡單不少。最靈活變化的應該是系統設計，沒實踐過，我也沒啥好說的。要費事的可能要數數據庫的開發，我感覺這有點像在修改DEMO之類的，雖每一個
不難，但數量眾多，要有耐心，不過重復的多，會越做越快的。到最后是用ATLAS開發，但估計一般的廠家會用如CVI、LabView之類的替代，道理也
很簡單，ATLAS編譯器太貴了，還不一定好用，而用NI等公司產品的無論是人還是相關資料都是比較多的，性價比高。
我對UUT程序的看法
這程序吧，思考的角度不一樣，得出得結果肯定會不一樣，還是那句話，要應時應勢而異。不管是寫程序還是根據已有的程序得到適合自己的程序時，基本也就要考慮以下部分：
一般測試流程為:(1)根據UUT的被測特征來為其分配一個合適的測試儀器;(2)將UUT和分配到的儀器連接起來;(3)測試儀器根據測試需求作出一些測試動作;(4)測試完畢后斷開連接。其中第1步是測試中最重要的一步。
也有這樣的流程：(1)證實待測UUT是否正確：(2)UUT安全檢測；(3)上電安全檢測；(4)讀故障存儲器； (5)BITE 測試：(6)UUT各功能測試。
還有這樣的，把ATLAS的每一步測量細分：1)將虛擬資源、信號類型、被測量及參數描述字符串映射翻具體的資源
；2)將連接描述字符串映射到具體的繼電器；3)閉合相應的繼電器； 4)延遲； 5)調資源的驅動，測量信號參數值
，并放到測量描述字符串對應的變量中； 6)斷開繼電器，儀器復位。
反正如果要是沒有PAWS之類的軟件或硬件不一樣，現有的軟件用處不大的話，有一點是一樣的，就需要人工實現由虛擬資源到實際資源的轉化，當然根據自己的硬件情況，寫個編譯器是最好的:-)。
我對資源的看法
先COPY一點：儀器的性能數據由REQUIRE語句提供。REQUIRE總結出了所有需要的測試資源，并把它們作為虛擬資源
。這些虛擬資源是根據UUT信號需求定義的，而不是根據在具體測試系統中所用實際資源的性能定義的，一個實際資源沒有必要只對應一個虛擬資源
。比如，一個現代的數字萬用表就可以對應多個虛擬資源，如包含交流電壓表，直流電壓表，電阻表，直流表等。其實實際資源與虛擬資源也可以說是多對多的關
系，有時一個檢測步驟需要測量N種參數，可以用多種儀器測量。在這里會存在一張資源分配表，而且應該是動態的，每個設備使用的時間甚至有什么特殊情況都是
不可預見的，使用完了才能釋放相應資源，讓其它接口使用。可編程開關、開關矩陣、繼電器等就是用來根據需要，動態地在ATE的實際資源和UUT之間起一個
連接作用的。當然如果系統比較簡單，可以人工靜態地給它分配好，這樣無論是寫程序還是做硬件實現起來會很省事。基本原理我估計就是這樣，但實現起來，我沒
有實踐，也就沒發言權了。
我對根據已有的ATLAS制作ATE設備的看法
如果你同意以上我說的，請繼續往下看，否則對你來說可能是誤導:-)。
很多種情況下，我們都是已經有現成的CMM手冊，當然也有ATLAS源程序（應該叫測試規范，但叫程序習慣了，先入為主），但就是沒有對應的ATE硬件平臺，買不到或不想買那些硬件平臺，怎么辦，就要根據已有的ATLAS，已有的可買到的硬件制作ATE設備了。
前面說過，一般用如NI公司的一些產品來實現，但人家NI公司的產品不支持ATLAS，就要連同源ATLAS程序都要修改了，改成符合他們標準的如
LabView、CVI等支持的語言了。（等哪天中國強大了，也自己制作標準）。驅動也要用符合他們標準的，機箱也要用符合他們標準的，我相對比較關心的
就是如何根據ATLAS源程序選用什么樣的硬件，怎樣能把ATLAS源程序變為CVI程序。
說到這，我想起來一個笑話，說某一天，主持人問大家，有一個水龍頭，一個空壺，一個爐子，怎樣才能得到一壺熱水，大家說，先把水壺裝滿水，再放爐子上燒
熱，就可以了。 再問如果壺里有水，怎么辦？一物理學家說，直接放到爐子上燒熱就可以了。一數學家說，把壺里水倒掉，然后按照大家剛才說的那樣去做。
我想程序之間的轉化，我愿意成為那個數學家。有時雖然這一段ATLAS語言你很容易明白，甚至你可以簡單地用一個C語句表示，但整本ATLAS語言就不能
每句都是那樣了，每句都要分析透徹到干啥干啥的，起什么作用，在這段占什么地位也不容易，也不省事，也未必是件好事。ATLAS中的動詞就那么幾個，無非
是比較，測量得到一個什么結果，發送點什么信號啊、碼啊，再有就是如延時、要求于用戶互動，要求用戶輸入，再給用戶輸出點什么，這些東西應該完全能用C語
言替代，甚至可以到一句替代一句的程度，只是一般用C還省事一些。
有人說替代不會得到我要的那種圖形化界面的要求，這是肯定的，當初人家美國人寫ATLAS語句的時候WINDOWS可能還沒出世呢，但得到一個DOS界面
下的程序還是完全可以的。有人說你C語言能實現虛擬資源到真實資源的轉化嗎？那本來應該是ATLAS編譯器的事，這就是我下面要說的重點。還有其它問題，
如ATLAS能一句就實現測量什么什么參數，C能嗎？C當然用函數實現，調用下層函數，直至驅動真實儀器工作（一般應該是數據采集卡一類的），然后由真實
儀器返回參數，直至剛才調用它的C語言函數。當然了，實現起來應該可能是比較麻煩，但思路是很清晰的，不會有理論上的難點。其它如發送什么特定格式的數
據，加身什么電壓、電流都可以依此類推，至于加什么電阻、電容、電感之類的，雖然沒有特定的儀器，但可以用可編程矩陣開關、可編程電阻等實現，理論上不
難，實際上我還沒實踐過，不說了。
我對虛擬資源轉實際資源的看法
這應該是個難點，我閉門造車，想出了一種方法，自認為簡單實用。
不管是虛擬資源還是實際資源，都要有一張表，暫稱為虛擬資源表和實際資源表，關鍵就是把這兩者一一聯系起來。虛擬資源程序很好實現，要什么，在表中做個標
記，用完了，再做個標記。實際資源也可以根據真實儀器來實現，在用的有一個標記，空閑的有一個標記，在系統執行每個測量函數之類的，這表都要檢查，這樣雖
然可能系統每執行一句，這兩個表都可能有改動，但現在計算機速度很快，這就是小菜一碟，內存1G才100多，不在乎。當然還有一張表，就是虛擬資源到實際
資源之間的連接表，這個就涉及開關矩陣和適配器了，我最多每用一次查一遍。所有的這些都是用的時候去查，去臨時構建，這樣就省去了麻煩。有人用有向圖動態
實現，算法復雜。有人基于靜態的資源關系，人為先配置好，雖編程簡單，但人為把資源匹配，數據多的時候較費人力。自我感覺有些創意，還小高興一下，但發現
郭瑞的論文早就提到，諸位想得到比較嚴謹的說法，還是看看人家寫的。
但有一點可以說是我獨創，用C++中的CLASS來做比喻，可以充分利用CLASS的繼承、派生特性，ATLAS中的REQUIRE完全可以定義為
CLASS，測量語句中的MEASURE就如同CLASS的實體，測量范圍比原定義小，是派生，又省去寫不少重復的要求，是繼承，再小高興一下。
話說到此處，該說的也差不多都說了，但要實現起來，還是比較艱巨的。ATE這一塊是博大精深，我現在涉及的只是冰山一角，感謝眾多前輩做的工作，使我可以
延著你們已經開辟的道路走下去。本文沒打算做論文寫，文中引用的語句皆未標出來源（本人也比較懶）,望見量。其實要得到這些出處也不難，keywords
用ATLAS的論文就是了，總共也沒幾篇。在此再次請求，誰有ATLAS編譯器如PAWS，共享之，不勝感激。Email：xiazhifei@yahoo.com.cn
|