??? 針對多種UUT的通用ATS軟件設(shè)計開發(fā)過程中，UUT和測試資源的種類和數(shù)量將激增，同時TPS也將有多個。為此，要對圖1所示ATS軟件概念模型進行擴展，由二維模形轉(zhuǎn)變成三維模形，如圖2所示。圖1和圖2的內(nèi)涵是一樣的，只不過在三維概念模型中，存在多個UUT和多個測試資源通過多個TPS實現(xiàn)的多對多映射關(guān)系，失去了兩維模型中一對一映射關(guān)系的單純性，而這也是當(dāng)前ATS軟件開發(fā)過程中具體工程應(yīng)用現(xiàn)狀的客觀體現(xiàn)。

?

??? ATS軟件概念模型需要實現(xiàn)兩部分內(nèi)容，分別是測試信息的描述和測試程序" title="測試程序">測試程序的實現(xiàn)。為此，本文把這兩個方面分別用信息模型和系統(tǒng)模型來描述。
2 軟件ATS信息模型
??? 在ATS軟件概念模型中，信息是核心要素，如何來描述和交換信息是ATS軟件實現(xiàn)的關(guān)鍵。ATS軟件信息模型是在概念模型的基礎(chǔ)上，主要對其信息要素進行建模，從信息描述和交換的角度深刻挖掘ATS軟件的本質(zhì)。
??? 本文把數(shù)據(jù)庫理論中的實體-關(guān)系圖模型進行了擴展，界定實體-關(guān)系圖中的實體不僅僅是物理實體，也可以包括行為實體和數(shù)據(jù)實體，而把它們統(tǒng)一稱為信息實體?；诖?，采用實體-關(guān)系圖模型構(gòu)建的ATS軟件信息模型如圖3所示。

?

?

??? 在ATS信息模型中，主要有三個重要的信息實體：測試、診斷和維修。位于某一測試上下文中的UUT由測試行為來標記其正常測試規(guī)格，而異常行為標記其故障特征，UUT通過測試端口與測試資源通訊，建立物理連接關(guān)系；測試實體通過測試資源實現(xiàn)與UUT的物理連接，并運行自身的TPS控制儀器資源來實現(xiàn)觀測UUT某一端口上的測試行為的目的，這一過程得到的測試數(shù)據(jù)作為故障診斷推理和標記UUT異常行為的基礎(chǔ)；診斷實體建立在依據(jù)UUT模型得到的診斷知識之上，它首先根據(jù)診斷任務(wù)選擇測試活動并對其進行排序從而生成測試執(zhí)行序列，其次診斷實體參考測試數(shù)據(jù)標記UUT的某一異常行為出現(xiàn)與否，而后通過診斷模型對異常行為的具體位置、故障現(xiàn)狀等情況進行判定，最后通過一系列維修活動糾正UUT的異常行為，從而實現(xiàn)服務(wù)于UUT維修保障的最終目的。
??? 為了清楚地描述測試信息，本文提取和定義了ATS軟件信息模型中的信息實體，信息實體包括被測對象UUT、UUT測試、測試儀器" title="測試儀器">測試儀器、測試平臺" title="測試平臺">測試平臺、測試適配器、測試配置、測試數(shù)據(jù)、故障診斷和故障維修等九個，各自的描述范疇和內(nèi)容如下所示：被測對象UUT提供了描述某一特定UUT的能力，包括UUT的標識、接口以及物理、電氣、操作特性等信息，它用來輔助UUT測試描述信息實體生成可執(zhí)行的TPS，并保證該TPS在不同ATS之間移植；UUT測試描述UUT基本信息、測試性能、測試條件、電源需求、測試序列、診斷需求、相關(guān)支持設(shè)備的連接和操作以及測試程序的自動生成等信息，這些信息是開發(fā)可執(zhí)行TPS的基礎(chǔ)；測試配置描述在具體的測試平臺上測試某一個UUT所必須的硬件、軟件與文檔信息，這些信息指向了其他信息實體；測試適配器描述UUT與測試平臺之間的連接關(guān)系，包括應(yīng)用環(huán)境需求、連接接口、物理/電氣特性等信息，這些信息用于描述適配器的適用環(huán)境，定位UUT和ATE（Automated Test Equipment）之間的信號路徑，便于實現(xiàn)TPS的移植性；測試平臺描述平臺上測試資源的接口、物理/電氣特性、通道、校準以及自檢等信息，其為ATS自檢和校準以及TPS執(zhí)行時的通道轉(zhuǎn)換和信號路由提供服務(wù)；測試儀器主要是對傳統(tǒng)儀器、綜合/虛擬/組合儀器進行靜態(tài)描述，該描述信息為TPS運行時標定儀器和進行資源分配提供服務(wù)，描述內(nèi)容包括儀器生產(chǎn)商、序列號、功能、端口、指標等信息；測試結(jié)果描述在某一ATE上執(zhí)行TPS進行某一UUT測試時的測試數(shù)據(jù)定義信息，包括UUT描述、測試平臺描述、測試程序TPS、測試值、對測試結(jié)果通過與否的判定、操作人員、先前的維修活動以及操作環(huán)境等，測試數(shù)據(jù)信息用于分析、處理、顯示和共享以及后期的故障診斷操作；診斷描述執(zhí)行和分析UUT某一故障所必需的診斷推理信息和過程定義，這些信息用于閉環(huán)故障診斷及其相關(guān)操作；維修信息描述在故障診斷結(jié)果的基礎(chǔ)上所要進行的維修活動。
??? ATS信息模型通過標記測試環(huán)境中的物理實體（如被測對象UUT、測試儀器等）、行為實體（如測試行為、診斷行為、維修行為等）和數(shù)據(jù)實體（如測試數(shù)據(jù)、診斷知識等）來完整地展現(xiàn)ATS信息實體之間的關(guān)系，描述了ATS內(nèi)部的UUT測試需求信息和測試資源功能信息的流動過程，為ATS系統(tǒng)模型的實現(xiàn)提供了信息支持。
??? 有關(guān)基于XML語言的信息實體描述方法參見文獻[2]，不再贅述。
3 ATS軟件系統(tǒng)模型
??? ATS軟件系統(tǒng)模型從開發(fā)人員的角度對ATS軟件的TPS設(shè)計進行建模，旨在依靠計算機軟件實現(xiàn)自動化的ATS信息交互過程。
為了清楚地描述ATS軟件的層次結(jié)構(gòu)，本文把ATS軟件系統(tǒng)模型建立在ABBET層狀模型^[3]基礎(chǔ)之上，如圖4所示。

?

??? ATS系統(tǒng)模型共分成六個層次：產(chǎn)品描述層、測試需求/策略層、測試程序?qū)印①Y源管理層、儀器控制層和硬件層。采用層狀結(jié)構(gòu)的最大好處是可以體現(xiàn)ATS軟件的整體結(jié)構(gòu)和接口連接關(guān)系。ATS軟件系統(tǒng)模型的層次劃分與ABBET標準定義的ATS層狀模型的主要區(qū)別是增加了硬件層，旨在便于把系統(tǒng)模型中需要的測試信息和接口信息與ATS硬件的對應(yīng)關(guān)系體現(xiàn)出來。
??? 在ATS軟件系統(tǒng)模型的接口連接關(guān)系上，各層之間分別通過產(chǎn)品描述文檔、測試/診斷需求描述文檔、虛擬資源、儀器驅(qū)動器和硬件總線接口實現(xiàn)連接。
3.1 產(chǎn)品描述層和測試需求/策略層
??? 從UUT測試和故障診斷的角度出發(fā)，產(chǎn)品描述層和測試需求/策略層是一致的，目的均是描述UUT的測試/診斷需求，二者的不同之處在于產(chǎn)品描述層在UUT設(shè)計階段定義UUT的測試行為，進而形成測試需求文檔傳遞到UUT的測試維修過程中去，而測試需求/策略層是在UUT的維護階段提取UUT的測試/診斷需求并給出測試/維修策略，進而形成測試需求文檔，因此產(chǎn)品描述文檔可以是UUT測試需求文檔的一部分或者就是UUT測試需求文檔本身。
??? 產(chǎn)品描述層和測試需求/策略層的實現(xiàn)對應(yīng)于ATS信息模型的UUT和UUT測試需求兩個信息實體，采用XML語言進行描述，詳細實現(xiàn)過程參見文獻[2]。
3.2 測試程序?qū)?BR>??? 在測試程序?qū)又校琓PS把UUT測試/診斷需求轉(zhuǎn)化為計算機可編譯執(zhí)行的軟件代碼，因此從深層次來講，TPS是對UUT測試/診斷需求的另一種表達方式，而這種方式可被COTS編譯器所理解和編譯運行，進而實現(xiàn)測試任務(wù)，得到測試數(shù)據(jù)，實現(xiàn)UUT的故障診斷和維修。
??? 測試程序的具體實現(xiàn)方法是多種多樣的，如基于ATLAS語言的實現(xiàn)方式、基于XSLT轉(zhuǎn)換語言的XML實現(xiàn)方法[5]和基于COTS語言的實現(xiàn)方法等。在這幾種實現(xiàn)方法中，ATLAS語言已經(jīng)過時且編譯器（如PAWS等）價格昂貴；基于XSLT轉(zhuǎn)換語言的XML方式缺乏規(guī)范的實現(xiàn)步驟且具體工程操作過程中工作量巨大，設(shè)計復(fù)用性差；而以COTS語言為工具，基于組件的ATS軟件設(shè)計實現(xiàn)方法是作者的最終選擇，詳細實現(xiàn)過程參見文獻[2]。
3.3資源管理層
??? 資源管理層是ATS軟件系統(tǒng)的重要組成部分，它實現(xiàn)了承載UUT測試需求的TPS和測試資源功能之間的對接，在儀器驅(qū)動器的支持下，為ATS軟件系統(tǒng)的儀器互換性、軟件移植性和系統(tǒng)互操作性問題提供了解決方案。
??? 在資源管理層中分別用測試儀器模型、測試平臺模型、測試適配器模型和測試配置模型規(guī)范了測試資源功能、測試平臺通道連接關(guān)系、測試適配器信號變換和通道轉(zhuǎn)接關(guān)系以及UUT測試配置等信息實體的描述內(nèi)容，它們是測試資源管理的基礎(chǔ)。在這四個模型中，前三個作為ATS中測試資源能力描述的組成部分，對ATS的測試功能進行描述，第四個提供UUT測試的系統(tǒng)配置信息。四個模型的實例化文檔共同為RTS提供信息支持，分別由ATS信息模型給出的測試儀器Schema、測試平臺Schema、測試適配器Schema和測試配置Schema進行定義，信息描述方法同樣采用XML格式。
??? 在測試資源管理信息的配合下，RTS將把TPS中標記的虛擬資源需求映射到真實的物理資源控制上來，這種映射關(guān)系是通過虛擬資源描述和物理資源能力描述中的信號索引來完成的^[1]。關(guān)于面向信號的測試資源能力映射方法參見文獻[2]。
??? 測試資源的能力是通過面向信號的儀器驅(qū)動器表現(xiàn)出來的，資源和通道映射成功后RTS將調(diào)用測試儀器和開關(guān)系統(tǒng)的驅(qū)動程序完成對物理儀器的功能調(diào)用。
3.4 儀器控制層
??? 儀器控制層完成測試儀器和開關(guān)通道的控制，面向信號的儀器驅(qū)動器設(shè)計在封裝內(nèi)部實現(xiàn)時可以調(diào)用的具體儀器驅(qū)動器類型有VPP、IVI、IVI-MSS等，而具體的物理控制指令可以是VISA、SCPI、488.2中的一種或幾種混合起來。
??? VISA規(guī)范屏蔽了測試儀器的物理接口，儀器接口可以是VXI、PXI、GPIB、PCI、LXI等類型中的任意一種。對于不同接口的測試儀器的相似功能，VISA均通過相同的控制代碼來實現(xiàn)。
4 模型之間的關(guān)系
??? 對于ATS而言，概念模型是ATS軟件模型的精髓所在，它是ATS軟件的靈魂，是信息模型和系統(tǒng)模型的出發(fā)點和立足點。信息模型解決ATS軟件概念模型的信息描述和交換問題，是ATS軟件系統(tǒng)模型需要解決的具體任務(wù)，它捕獲ATS軟件系統(tǒng)的信息需求，把整個ATS分成九個信息實體，劃分了各信息實體之間的接口關(guān)系和每個信息實體具體的描述范疇，這些信息實體作為TPS運行時系統(tǒng)的信息來源，方便了UUT測試需求信息和測試資源能力信息在ATS系統(tǒng)模型內(nèi)傳遞，約束了系統(tǒng)模型的行為。系統(tǒng)模型在RTS的支持下具體實現(xiàn)ATS的信息交互過程，它從ATS信息模型中獲取相關(guān)測試信息，是ATS信息交互過程的具體實現(xiàn)，ATS系統(tǒng)模型把測試軟件分成五個層次，各層次之間均由標準化接口來實現(xiàn)信息的傳遞和過程的調(diào)用。
??? ATS信息模型主要從用戶的角度對UUT的測試需求和實現(xiàn)過程建模，它描述ATS軟件的信息實體及其相互之間的關(guān)系，是不可執(zhí)行的，信息交互過程需要依靠系統(tǒng)模型來實現(xiàn)；而系統(tǒng)模型從設(shè)計實現(xiàn)TPS的角度對ATS軟件進行建模，它把UUT的測試需求信息和ATS測試資源能力信息轉(zhuǎn)化成ATS軟件實體，是可執(zhí)行的，而具體的信息需求要靠信息模型來提供。因此，從ATS軟件實現(xiàn)的角度來講，信息模型和系統(tǒng)模型之間的關(guān)系是對立統(tǒng)一的，整個ATS軟件開發(fā)過程需要把二者集成在一起。
??? 本文建立了ATS軟件的概念模型、信息模型和系統(tǒng)模型，闡述了三種模型之間的關(guān)系，解決了當(dāng)前由于ATS的規(guī)模和復(fù)雜度急劇增加帶來的ATS軟件系統(tǒng)集成和描述問題，對具體的ATS軟件工程設(shè)計和實現(xiàn)過程具有廣泛的指導(dǎo)作用。
參考文獻
[1] IEEE Std 1641-2004. IEEE Standard for Signal and Test Definition. 2004.
[2] ?劉金寧. 自動測試系統(tǒng)軟件模型與關(guān)鍵實現(xiàn)技術(shù)研究[D].軍械工程學(xué)院博士學(xué)位論文， 2007.
[3] ?IEEE Std 1226-1998. IEEE Trial Use Standard for A Broad Based Environment for Test（ABBET）Overview and Architecture[J]. 1998.
[4] ?SHEPPARD J W, SIMPSON W R. A systems view of test ?standardization[C]. In AUTOTESTCON, 1996.
[5] ?O’DONNELL S J, RICHARDSON P. Implementing ATML into an existing software architecture[C]. IEEE Proceedings of AUTOTESTCON 2004：209-216.