面向功能的測試設備驅動器設計與實現

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

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

0 引言

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

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

但在實際工程項目中，存在各種定制化的測試系統，內部集成了大量的非標準儀器和板卡。這些測試儀器和板卡來自不同的廠商，總線形式不一，其驅動程序未遵循現有的標準和規范，多使用自定義的指令集和控制函數，驅動程序的接口定義差別明顯，相互間很難兼容。

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

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

1 測試設備驅動器的設計原理

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

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

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

2 測試設備驅動器的接口設計

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

2.1 功能項目驅動接口的定義

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

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

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

1)基礎接口的定義

基礎接口IBasedSpecificDriver不涉及任何具體的測試功能，體現了公共性，其內容包括：

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

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

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

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

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

2.2 測試設備驅動器的對外接口定義

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

圖2 測試設備驅動器的接口模型Fig.2 Interface model of test equipment driver

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

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

2.3 測試設備驅動器的接口設計

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

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

IInstrumentManage接口負責管理該測試設備中的各種測試儀器和板卡，不涉及具體的測試功能。

2)設備資源的管理

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

3)設備驅動器基本操作

IDriverOperation接口中定義了測試設備驅動器自身獨有的基本操作，用于驅動器的初始化。

3 測試設備驅動器的實現

測試設備驅動器的對外接口為上層應用軟件提供了一個統一的操作端口，但測試軟件的執行必須建立在實際的測試設備硬件上，每個驅動器組件代表了某個具體的測試設備，描述了該設備如何實現各種規定的功能項目。

驅動器組件直接實現了測試設備驅動器接口IAteDriver，具體實現過程可以劃分為三部分：1)驅動器模型中定義的、具有公用性質的基礎功能的實現；2)該測試設備應具備的各種測試功能項目的實現；3)驅動器與上層應用軟件間的動態交互過程的實現。

3.1 基礎功能的實現

通過對測試設備驅動器接口模型的分析，驅動器需要實現的基礎功能包括以下內容。

? 項目驅動接口的創建

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

Function:CreateDriversInput:dict: 驅動接口列表Output:count:size of dict1:clear dict;2:建立串口測試項目驅動接口的實例D[0]3:add D[0] to dict;4:建立CAN測試項目驅動接口的實例D[1]5:add D[1] to dict;6:/*參考D[0],D[1],建立其他項目驅動實例,并增加到列表中*/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;

在實現IAteDriver接口時，主要的開發內容包括：

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

這些硬件初始化完畢后，分門別類地保存在驅動器中，作為后續各種功能項目的開發基礎。

? 設備資源管理功能的實現

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

圖3 測試設備的連接關系模型Fig.3 Connection relation model of test equipment driver

3.2 測試功能項目的開發

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

測試功能項目的開發步驟如下：

Step1:建立與功能項目驅動接口對應的實現類。

功能項目與設備驅動器是局部與整體的關系，功能項目實現類一般以內部嵌套類的形式存在，并由驅動器組件進行實例化。

Step2:驅動基礎接口的開發。

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

Step3:功能項目的具體實現。

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

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

? 儀器的操作

對于非標儀器，使用硬件廠商提供的API函數，或者經過二次開發而形成的封裝庫；對于標準儀器，可直接調用IVI類驅動或專用驅動組件。在驅動器組件開發和調試完畢后，除非硬件發生變化，否則不會修改該組件。

? 功能的實現

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

3.3 交互過程

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

圖4 測試設備驅動器的交互過程Fig.4 Interaction process of test equipment driver

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

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

4 應用實例

該測試設備驅動器的設計和開發方法已經在多個導航計算機測試軟件開發項目中得到了應用。導航計算機測試設備是一種典型的、用于電子產品測試的系列化產品，內部集成了多種PCI、CPCI等板卡和其他專用儀器，其驅動程序大部分都是由生產廠商自己定義的。該類軟件產品的整體結構示意圖如圖5所示。

圖5 驅動器的應用實例示意圖Fig.5 Application example of driver

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

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

5 結論

本文針對測試軟件開發中存在的非標準驅動程序問題，提出了一種面向功能的驅動器設計與開發方法。實際項目的應用表明,該方法具有以下特點：

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

2)測試設備驅動器對外提供了統一的規范化接口，提高了測試軟件的標準化水平，并具有良好的延續性，這對于周期較長的系列化軟件產品尤其重要;

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

通過測試設備驅動器，為各種系列化軟件產品的開發提供了統一的硬件控制接口定義和規范化的實現方案，減少了非標準驅動程序的差異性對軟件項目的影響，從而提高了測試程序的移植性和開發質量，滿足工程應用中系列化測試軟件的設計與開發的需要。