面向功能的測試設(shè)備驅(qū)動器設(shè)計與實現(xiàn)

秦振漢，胡廣明，張 輝, 郭雙紅

(1. 航天科工慣性技術(shù)有限公司，北京 100074； 2. 陸軍裝備部駐北京地區(qū)航空軍事代表室, 北京 100074)

0 引言

在自動測試系統(tǒng)中，一般都會在測試程序和硬件儀器的驅(qū)動程序之間建立一個軟件中間層，以連接計算機(jī)和各種不同測試儀器[1-2]。儀器驅(qū)動器是一組用于控制程控儀器的軟件單元，提供了規(guī)范化的軟件接口，簡化了具體的編程步驟，便于實現(xiàn)儀器功能的操作[3-4]。

測試儀器的種類、功能眾多，針對儀器驅(qū)動的標(biāo)準(zhǔn)問題，國內(nèi)外進(jìn)行了大量的工作，陸續(xù)推出了多種標(biāo)準(zhǔn)和規(guī)范，目的是提高儀器的可互換性和通用性水平。常用的儀器驅(qū)動標(biāo)準(zhǔn)包括SCPI、VPP、IVI-C、IVI-COM等，并在測控領(lǐng)域得到了廣泛的應(yīng)用[5-7]。這些標(biāo)準(zhǔn)的基本思想是把儀器的操作封裝成相同的接口，其函數(shù)名稱和參數(shù)完全相同，解決了儀器之間互換的問題[8-9]。

但在實際工程項目中，存在各種定制化的測試系統(tǒng)，內(nèi)部集成了大量的非標(biāo)準(zhǔn)儀器和板卡。這些測試儀器和板卡來自不同的廠商，總線形式不一，其驅(qū)動程序未遵循現(xiàn)有的標(biāo)準(zhǔn)和規(guī)范，多使用自定義的指令集和控制函數(shù)，驅(qū)動程序的接口定義差別明顯，相互間很難兼容。

為此，在工程應(yīng)用中，一般會對廠商提供的非標(biāo)準(zhǔn)驅(qū)動程序進(jìn)行二次封裝，形成專門針對特定儀器的封裝庫[9-10]。這種開發(fā)方式在獨(dú)立的軟件項目中問題不明顯，但是對于需要部署在多種測試設(shè)備上，用于解決多型號產(chǎn)品測試問題，以及開發(fā)、使用、維護(hù)周期較長的系列化軟件產(chǎn)品而言，則帶來了很多的問題。例如，缺乏統(tǒng)一的硬件控制方案，各測試程序的隨意性較強(qiáng)；軟件的移植性較差，當(dāng)硬件升級和改造后，已有的測試程序無法使用；軟件的復(fù)用性不高，重復(fù)開發(fā)的情況經(jīng)常出現(xiàn)。

本文從實際工程實踐出發(fā)，參考已有的研究成果[3,11-12]，提出了一種面向功能的測試設(shè)備驅(qū)動器的設(shè)計和開發(fā)方法。測試設(shè)備驅(qū)動器是溝通底層硬件驅(qū)動程序與上層測試軟件的橋梁，為軟件開發(fā)提供了統(tǒng)一的軟硬件接口，并規(guī)范了驅(qū)動器內(nèi)部的實現(xiàn)方式。通過對特定類別測試設(shè)備所需實現(xiàn)的硬件功能需求的抽象，最大程度地凝練共性內(nèi)容，并將它們整合在一起，形成脫離硬件環(huán)境的測試功能項目集合。上層測試程序針對這些完全虛擬化的功能項目進(jìn)行開發(fā)，不必了解底層各種異構(gòu)的測試儀器、板卡及其驅(qū)動程序所帶來的差異，可根據(jù)不同的業(yè)務(wù)需求，方便、靈活地實現(xiàn)對硬件資源的間接控制。同時，將不同設(shè)備間的差異性內(nèi)容封裝在驅(qū)動器組件的內(nèi)部，隨測試設(shè)備一起發(fā)布，共同構(gòu)成了上層測試軟件開發(fā)和運(yùn)行的基礎(chǔ)資源。

1 測試設(shè)備驅(qū)動器的設(shè)計原理

以用于實現(xiàn)電子產(chǎn)品功能和性能檢測的測試設(shè)備為例，該類設(shè)備的內(nèi)部集成了各種測試儀器和板卡，是測試功能的實現(xiàn)載體。這些儀器和板卡的種類、形式多樣，包括了PCI、CPCI、PXI等形式的模塊化板卡、外置的組合儀器、標(biāo)準(zhǔn)的臺式儀器等；實現(xiàn)的功能也各不相同，其中很多儀器都是針對特定需求而單獨(dú)開發(fā)的。

在設(shè)計測試設(shè)備驅(qū)動器時，目前經(jīng)常使用的是以測試儀器為中心的設(shè)計方式，即直接針對各種測試儀器和板卡的驅(qū)動程序進(jìn)行測試程序的開發(fā)。此時，上層應(yīng)用軟件直接控制底層的硬件資源，當(dāng)測試程序在不同設(shè)備之間移植或測試儀器改變時，測試程序需要進(jìn)行大量改動，可移植性和重用性較差[14]，顯然無法滿足定制化設(shè)備的軟件開發(fā)要求。

為此，本文采用了針對功能的驅(qū)動器設(shè)計方式，其關(guān)注點不是各種異構(gòu)的儀器或板卡，而是更高一層的設(shè)備層面。通過對測試設(shè)備硬件功能的分析，抽象出該類設(shè)備的各種測試功能。測試設(shè)備驅(qū)動器針對的是該類設(shè)備需要實現(xiàn)的系統(tǒng)級測試功能，而不再是各種異構(gòu)的儀器或板卡。這種以功能為中心的設(shè)計方式，有效屏蔽了底層硬件的差異性內(nèi)容，使得驅(qū)動器具有更好的穩(wěn)定性和擴(kuò)展性。

2 測試設(shè)備驅(qū)動器的接口設(shè)計

驅(qū)動器接口的設(shè)計內(nèi)容包括：在驅(qū)動器的內(nèi)部建立功能項目驅(qū)動接口，用于表示各種測試功能；在驅(qū)動器的外部為上層應(yīng)用提供統(tǒng)一的對外操作接口，以及該驅(qū)動器自身應(yīng)包含的、輔助性的功能性接口。

2.1 功能項目驅(qū)動接口的定義

功能項目驅(qū)動接口描述了某個功能項目的具體細(xì)節(jié)，代表了一種完全抽象的系統(tǒng)級功能，與硬件(包括測試儀器、板卡、測試設(shè)備等)無關(guān)，因而更加具有普遍性。該接口的定義模型如圖1所示。

圖1 測試功能項目驅(qū)動接口的定義Fig.1 Definition of test functional item driver interface

所有的項目驅(qū)動接口都繼承自基礎(chǔ)接口IBa-sedSpecificDriver，由后者反映各驅(qū)動接口具有的共性內(nèi)容，在定義后不會被修改，對外提供了驅(qū)動接口的一致性描述信息。

1)基礎(chǔ)接口的定義

基礎(chǔ)接口IBasedSpecificDriver不涉及任何具體的測試功能，體現(xiàn)了公共性，其內(nèi)容包括：

IDriverUtility：提供一組最基本的操作方法，如使能、復(fù)位、錯誤查詢等；

IDriverIdentity：對外提供了該測試功能項的識別信息，其中最重要的內(nèi)容是一個用以標(biāo)明每個實現(xiàn)組件功能類別的唯一標(biāo)識符；

IDriverManage：完成各種功能項目驅(qū)動接口的創(chuàng)建、集成和檢索，在驅(qū)動器中提供了一個獨(dú)立的驅(qū)動接口列表，集中管理該驅(qū)動器含有的各種測試功能項目。

2)功能項目驅(qū)動接口的定義

每個功能項目驅(qū)動接口(ITestItemDriver)表示了一個獨(dú)立的測試功能項目，眾多驅(qū)動接口組織在一起，構(gòu)成了一個虛擬化的測試設(shè)備，具備了該類測試設(shè)備的各種硬件測試功能。

2.2 測試設(shè)備驅(qū)動器的對外接口定義

測試設(shè)備驅(qū)動器的對外接口(IAteDriver)是對外提供的唯一端口，屏蔽了驅(qū)動器內(nèi)部的具體實現(xiàn)，該接口的定義模型如圖2所示。

圖2 測試設(shè)備驅(qū)動器的接口模型Fig.2 Interface model of test equipment driver

驅(qū)動器接口采用了組合模式(Composite Pattern),內(nèi)部包含了N個測試功能項目接口。從物理意義上分析，該模型表示自動化測試設(shè)備具有了N種不同的獨(dú)立測試功能，并可根據(jù)設(shè)備發(fā)展情況隨時進(jìn)行擴(kuò)展，但不會影響測試設(shè)備的對外描述。

該驅(qū)動器的對外接口可以應(yīng)用在不同類別、不同型號的測試軟件開發(fā)中，換言之，對于上層應(yīng)用軟件而言，可忽略因硬件設(shè)備和儀器的差異性所帶來的影響，使得應(yīng)用開發(fā)人員可以將工作重心集中于業(yè)務(wù)邏輯本身，更加方便、靈活地應(yīng)對上層軟件的需求和變化。

2.3 測試設(shè)備驅(qū)動器的接口設(shè)計

測試設(shè)備驅(qū)動器的對外接口繼承了IBasedSpecificDriver，自身已經(jīng)具備了功能項目驅(qū)動接口定義的各種操作。除此之外，還提供了3個額外的輔助接口，表示了驅(qū)動器需要具有的特殊操作。

1)測試儀器和板卡的管理

IInstrumentManage接口負(fù)責(zé)管理該測試設(shè)備中的各種測試儀器和板卡，不涉及具體的測試功能。

2)設(shè)備資源的管理

在驅(qū)動器設(shè)計時，采用數(shù)據(jù)模型的方式，描述了測試設(shè)備和被測產(chǎn)品的物理特性[13]。資源管理接口IAteResource的核心任務(wù)是提供被測產(chǎn)品的輸入輸出端口和測試儀器的資源端口之間的映射關(guān)系。

3)設(shè)備驅(qū)動器基本操作

IDriverOperation接口中定義了測試設(shè)備驅(qū)動器自身獨(dú)有的基本操作，用于驅(qū)動器的初始化。

3 測試設(shè)備驅(qū)動器的實現(xiàn)

測試設(shè)備驅(qū)動器的對外接口為上層應(yīng)用軟件提供了一個統(tǒng)一的操作端口，但測試軟件的執(zhí)行必須建立在實際的測試設(shè)備硬件上，每個驅(qū)動器組件代表了某個具體的測試設(shè)備，描述了該設(shè)備如何實現(xiàn)各種規(guī)定的功能項目。

驅(qū)動器組件直接實現(xiàn)了測試設(shè)備驅(qū)動器接口IAteDriver，具體實現(xiàn)過程可以劃分為三部分：1)驅(qū)動器模型中定義的、具有公用性質(zhì)的基礎(chǔ)功能的實現(xiàn)；2)該測試設(shè)備應(yīng)具備的各種測試功能項目的實現(xiàn)；3)驅(qū)動器與上層應(yīng)用軟件間的動態(tài)交互過程的實現(xiàn)。

3.1 基礎(chǔ)功能的實現(xiàn)

通過對測試設(shè)備驅(qū)動器接口模型的分析，驅(qū)動器需要實現(xiàn)的基礎(chǔ)功能包括以下內(nèi)容。

? 項目驅(qū)動接口的創(chuàng)建

在實現(xiàn)IBasedSpecificDriver接口時，核心的功能是實現(xiàn)各種功能項目驅(qū)動接口的實例化，并將其組裝在驅(qū)動接口列表中。該功能由IDriverManage接口的CreateDrivers函數(shù)實現(xiàn)，其偽代碼如下：

Function:CreateDriversInput:dict: 驅(qū)動接口列表Output:count:size of dict1:clear dict;2:建立串口測試項目驅(qū)動接口的實例D[0]3:add D[0] to dict;4:建立CAN測試項目驅(qū)動接口的實例D[1]5:add D[1] to dict;6:/*參考D[0],D[1],建立其他項目驅(qū)動實例,并增加到列表中*/7:for each IBasedSpecificDriver D[i] in dict do8:if D[i].DriverManager ≠ null then9:D[i].DriverManager.CreateDrivers();10: end if11:end for12:return dict.Count;

在實現(xiàn)IAteDriver接口時，主要的開發(fā)內(nèi)容包括：

? 測試儀器和板卡的初始化

這些硬件初始化完畢后，分門別類地保存在驅(qū)動器中，作為后續(xù)各種功能項目的開發(fā)基礎(chǔ)。

? 設(shè)備資源管理功能的實現(xiàn)

該功能的主要目的是實現(xiàn)被測產(chǎn)品的測試需求、測試設(shè)備提供的測試資源、測試儀器的測試能力三者之間的匹配，從而獲得被測產(chǎn)品和測試設(shè)備之間的測試路徑。本文參考現(xiàn)有研究成果[14-15]，并結(jié)合工程實踐，建立了如圖3所示測試設(shè)備的連接關(guān)系模型，以描述自動測試設(shè)備內(nèi)外的電氣特性。

圖3 測試設(shè)備的連接關(guān)系模型Fig.3 Connection relation model of test equipment driver

3.2 測試功能項目的開發(fā)

對于驅(qū)動接口列表中的每項內(nèi)容，都需要在驅(qū)動器組件開發(fā)時一一予以實現(xiàn)。每個功能項目最終都要落實到硬件儀器上，因而驅(qū)動器組件是和自動測試設(shè)備緊密耦合在一起的。在驅(qū)動器組件內(nèi)部，通過調(diào)用各種異構(gòu)的驅(qū)動程序，實現(xiàn)該測試設(shè)備的設(shè)計要求，從而將對外提供的各種虛擬測試項目轉(zhuǎn)換為真實的測試功能。

測試功能項目的開發(fā)步驟如下：

Step1:建立與功能項目驅(qū)動接口對應(yīng)的實現(xiàn)類。

功能項目與設(shè)備驅(qū)動器是局部與整體的關(guān)系，功能項目實現(xiàn)類一般以內(nèi)部嵌套類的形式存在，并由驅(qū)動器組件進(jìn)行實例化。

Step2:驅(qū)動基礎(chǔ)接口的開發(fā)。

完成基礎(chǔ)接口中定義的三項內(nèi)容，其中尤其注意的是測試功能項的識別信息。

Step3:功能項目的具體實現(xiàn)。

? 測試路徑的查詢，以獲得完整的測試路徑。

以圖3為例，從右至左，獲得從產(chǎn)品端口J1映射到測試板卡R2通道的測試路徑，并以該板卡為真正的硬件執(zhí)行單元，利用通道R2進(jìn)行信號的發(fā)送和采集。

? 儀器的操作

對于非標(biāo)儀器，使用硬件廠商提供的API函數(shù)，或者經(jīng)過二次開發(fā)而形成的封裝庫；對于標(biāo)準(zhǔn)儀器，可直接調(diào)用IVI類驅(qū)動或?qū)Ｓ抿?qū)動組件。在驅(qū)動器組件開發(fā)和調(diào)試完畢后，除非硬件發(fā)生變化，否則不會修改該組件。

? 功能的實現(xiàn)

功能項目面向的是測試設(shè)備的系統(tǒng)級功能，不僅僅是對儀器的簡單操作。以模擬量采集為例，當(dāng)使用數(shù)字萬用表時，測量數(shù)值已經(jīng)由儀器處理，可以直接讀取；但使用PCI板卡時，需要對高速采集的多組連續(xù)數(shù)值進(jìn)行必要的信號處理(如平滑、去除野點等)，才可以得到比較準(zhǔn)確的數(shù)據(jù)。

3.3 交互過程

圖4以序列圖(Sequence Diagram)的形式，描述了在典型應(yīng)用場景下，應(yīng)用軟件與測試設(shè)備驅(qū)動器之間的交互過程，闡述了在測試軟件運(yùn)行過程中，各方的執(zhí)行順序及所起到的作用。

圖4 測試設(shè)備驅(qū)動器的交互過程Fig.4 Interaction process of test equipment driver

從圖4可以明顯看出，在上層應(yīng)用軟件和測試儀器驅(qū)動程序之間增加了測試設(shè)備驅(qū)動器(功能項目實例是驅(qū)動器的一部分，為說明方便，特將其單獨(dú)列出)，進(jìn)而隔斷了兩者的直接關(guān)聯(lián)。

在序列圖中，消息1.0～1.6描述了驅(qū)動器組件的創(chuàng)建過程，驅(qū)動器由上層應(yīng)用軟件建立，并配置各種資源信息；各功能項目的建立、硬件儀器的初始化等由驅(qū)動器自身實現(xiàn)，與外部無關(guān)。消息2.0～2.9描述了測試業(yè)務(wù)的執(zhí)行過程，業(yè)務(wù)邏輯只能通過應(yīng)用軟件賦予的驅(qū)動器接口進(jìn)行開發(fā);在業(yè)務(wù)邏輯內(nèi)部，查找到需要的測試功能項目驅(qū)動接口，并通過后者，根據(jù)匹配的儀器信息，實現(xiàn)對某個測試儀器的操作。消息3.0～3.3描述了驅(qū)動器的銷毀過程，該過程同樣由上層應(yīng)用軟件發(fā)起。

4 應(yīng)用實例

該測試設(shè)備驅(qū)動器的設(shè)計和開發(fā)方法已經(jīng)在多個導(dǎo)航計算機(jī)測試軟件開發(fā)項目中得到了應(yīng)用。導(dǎo)航計算機(jī)測試設(shè)備是一種典型的、用于電子產(chǎn)品測試的系列化產(chǎn)品，內(nèi)部集成了多種PCI、CPCI等板卡和其他專用儀器，其驅(qū)動程序大部分都是由生產(chǎn)廠商自己定義的。該類軟件產(chǎn)品的整體結(jié)構(gòu)示意圖如圖5所示。

圖5 驅(qū)動器的應(yīng)用實例示意圖Fig.5 Application example of driver

針對每個自動測試設(shè)備(ATE1，ATE2，ATE3)，在設(shè)備驅(qū)動層中都提供了一個虛擬的設(shè)備驅(qū)動器組件(Driver1,Driver2,Driver3)，以屏蔽底層硬件驅(qū)動和硬件電氣設(shè)計的差異，并在內(nèi)部集成了該設(shè)備所具有的各種功能(I1,I2, ……,Im)。設(shè)備驅(qū)動器組件反映了各種測試設(shè)備具有的硬件功能，作為上層應(yīng)用軟件的運(yùn)行基礎(chǔ)，在開發(fā)完畢后可全局復(fù)用。

測試業(yè)務(wù)層中采用了增量開發(fā)方法，可根據(jù)不同被測產(chǎn)品的特定測試要求而擴(kuò)展新的業(yè)務(wù)組件(TestA，TestB，……,TestF)。這些業(yè)務(wù)組件只能通過測試設(shè)備驅(qū)動器接口完成對硬件層的功能操作。在該類測試軟件中，應(yīng)用軟件開發(fā)人員只需了解測試設(shè)備具有的測試功能，從而將主要工作集中在業(yè)務(wù)邏輯部分，提高了開發(fā)效率和質(zhì)量。

5 結(jié)論

本文針對測試軟件開發(fā)中存在的非標(biāo)準(zhǔn)驅(qū)動程序問題，提出了一種面向功能的驅(qū)動器設(shè)計與開發(fā)方法。實際項目的應(yīng)用表明,該方法具有以下特點：

1)測試設(shè)備驅(qū)動器位于業(yè)務(wù)層和設(shè)備硬件層之間，有效降低了各測試程序與設(shè)備硬件層之間的直接耦合性，便于測試程序在多個測試設(shè)備上重用和移植;

2)測試設(shè)備驅(qū)動器對外提供了統(tǒng)一的規(guī)范化接口，提高了測試軟件的標(biāo)準(zhǔn)化水平，并具有良好的延續(xù)性，這對于周期較長的系列化軟件產(chǎn)品尤其重要;

3)采用上層業(yè)務(wù)程序與測試儀器驅(qū)動程序分離的設(shè)計方法，促進(jìn)軟硬件開發(fā)的分工與合作，提高了專業(yè)化水平,并將對硬件的全部操作集中在驅(qū)動器組件中，避免了重復(fù)開發(fā)，提高了開發(fā)質(zhì)量。

通過測試設(shè)備驅(qū)動器，為各種系列化軟件產(chǎn)品的開發(fā)提供了統(tǒng)一的硬件控制接口定義和規(guī)范化的實現(xiàn)方案，減少了非標(biāo)準(zhǔn)驅(qū)動程序的差異性對軟件項目的影響，從而提高了測試程序的移植性和開發(fā)質(zhì)量，滿足工程應(yīng)用中系列化測試軟件的設(shè)計與開發(fā)的需要。