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

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

0 引言

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

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

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

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

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

1 測(cè)試設(shè)備驅(qū)動(dòng)器的設(shè)計(jì)原理

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

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

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

2 測(cè)試設(shè)備驅(qū)動(dòng)器的接口設(shè)計(jì)

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

2.1 功能項(xiàng)目驅(qū)動(dòng)接口的定義

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

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

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

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

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

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

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

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

2)功能項(xiàng)目驅(qū)動(dòng)接口的定義

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

2.2 測(cè)試設(shè)備驅(qū)動(dòng)器的對(duì)外接口定義

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

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

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

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

2.3 測(cè)試設(shè)備驅(qū)動(dòng)器的接口設(shè)計(jì)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

? 測(cè)試儀器和板卡的初始化

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

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

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

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

3.2 測(cè)試功能項(xiàng)目的開發(fā)

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

測(cè)試功能項(xiàng)目的開發(fā)步驟如下：

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

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

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

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

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

? 測(cè)試路徑的查詢，以獲得完整的測(cè)試路徑。

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

? 儀器的操作

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

? 功能的實(shí)現(xiàn)

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

3.3 交互過程

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

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

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

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

4 應(yīng)用實(shí)例

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

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

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

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

5 結(jié)論

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

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

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

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

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