秦振漢,林 淵,胡廣明,郭雙紅
(航天科工慣性技術(shù)有限公司,北京 100074)
儀器互換性是衡量測控系統(tǒng)的重要指標(biāo),也是測試軟件設(shè)計和開發(fā)時面對的重點問題。提高互換性的目的是當(dāng)測試設(shè)備儀器升級或替換后, 不會對現(xiàn)有的測試軟件造成太大影響;同時便于已有測試程序向其他測試設(shè)備的移植[1]。目前,已經(jīng)陸續(xù)推出了多種儀器互換標(biāo)準(zhǔn)、規(guī)范[2-5],并在測控領(lǐng)域得到了廣泛的應(yīng)用。但在實際工程項目中,仍然存在大量的非標(biāo)準(zhǔn)儀器、板卡,這些儀器的驅(qū)動程序未遵循或未完全遵循現(xiàn)有的標(biāo)準(zhǔn),而是使用廠商自定義的指令集、API函數(shù),相互間無法兼容。由這些非標(biāo)準(zhǔn)儀器、板卡構(gòu)成的專用測試設(shè)備,在測試軟件開發(fā)中無法使用現(xiàn)有的互換性技術(shù),當(dāng)板卡或儀器進行升級或替換時,由于特定驅(qū)動程序的改變,經(jīng)常導(dǎo)致現(xiàn)有的測試程序無法使用;同時,測試軟件和硬件驅(qū)動程序直接相關(guān),無法快速、方便地移植其它測試設(shè)備上,測試軟件的可移植性很低。
為此,通過對開發(fā)實踐的歸納和總結(jié),本文提出了一種提高專用測試設(shè)備互換性的工程實現(xiàn)方法。該方法忽略了各種儀器或板卡的具體實現(xiàn)細節(jié),將關(guān)注點放在更高一層的測試設(shè)備層面,通過對測試設(shè)備需要實現(xiàn)的測試需求的抽象,建立標(biāo)準(zhǔn)化的測試需求接口集合,并通過對這些接口的組合,建立特定的測試設(shè)備驅(qū)動接口。業(yè)務(wù)邏輯程序只依賴該接口,不涉及硬件的實現(xiàn)細節(jié)。同時,將測試儀器或板卡的具體操作封裝在驅(qū)動組件內(nèi)部,并與配置文件一起發(fā)布,描述了測試設(shè)備的實現(xiàn)細節(jié)。
通過這種方式,為測試軟件的開發(fā)提供了規(guī)范的接口定義,業(yè)務(wù)邏輯面向接口進行開發(fā),便于現(xiàn)有軟件在不同測試設(shè)備上的移植;同時,將各種非標(biāo)準(zhǔn)儀器驅(qū)動對測試軟件的影響控制在驅(qū)動組件內(nèi)部,提高了測試設(shè)備的儀器互換性。
目前常用的儀器互換性技術(shù)包括: SCPI互換、VPP互換、ATLAS語言規(guī)范、IVI-C、IVI-COM、IVI-MSS、IVI-Signal互換[2-5]等。這些技術(shù)可分為面向儀器的互換和面向信號的互換等兩類[5]。其中,SCPI互換、VPP互換、IVI-C和IVI-COM互換等屬于面向儀器的互換, 其基本思想是把同類儀器的操作封裝成相同的接口,其函數(shù)名稱、參數(shù)相同,主要解決同類儀器之間互換問題。但實際上隨著儀器的功能、種類越來越多,已經(jīng)很難對儀器進行明確的分類,也不能覆蓋所有的測試儀器。面向信號的互換技術(shù)包括ATLAS語言規(guī)范、IVI-MSS、IVI-Signal互換等,其基本思想是按照儀器支持的信號功能對測試資源進行分類,相同的信號具有相同的函數(shù)接口。雖然測試程序可以面向信號方式實現(xiàn),但是對各種物理儀器的操作仍然需要調(diào)用各種驅(qū)動程序來實現(xiàn)。
在專用測試設(shè)備開發(fā)中,需要使用大量的PCI、CPCI嵌入式板卡和其他一些非標(biāo)準(zhǔn)儀器。這些儀器的驅(qū)動程序由不同廠商、在不同的時間開發(fā),并沒有遵守統(tǒng)一的標(biāo)準(zhǔn)或規(guī)范。有些測試儀器、板卡是針對特定需求而定制開發(fā)的,本身就沒有可供參考的標(biāo)準(zhǔn)。
以導(dǎo)航計算機測試設(shè)備為例,這是一個由多種測試設(shè)備組成的系列化產(chǎn)品,用于各型導(dǎo)航計算機的測試,在產(chǎn)品研試、小批量試制和生產(chǎn)交付階段中廣泛應(yīng)用。該類測試設(shè)備受功能需求、時間、成本、通用化、系列化等因素的影響,使用了很多的非標(biāo)儀器和板卡。表1羅列了典型測試設(shè)備中幾種常用儀器的選型情況。
表1 幾種典型導(dǎo)航計算機測試設(shè)備的硬件構(gòu)成
從表1的情況可知,除少數(shù)儀器(以斜體標(biāo)識)外,大多數(shù)儀器、板卡的驅(qū)動程序都不是按照現(xiàn)有標(biāo)準(zhǔn)開發(fā)的。此外,有些專門定制的板卡,其類別已經(jīng)很難劃分,也無法采用面向信號方式描述。這種情況在專用測試設(shè)備中很常見,給互換性開發(fā)帶來了很大的困難。
針對這種情況,參考已有的研究成果[6-8],結(jié)合實際工程實踐,建立了如圖1所示的專用測試設(shè)備的互換性模型。
圖1使用統(tǒng)一建模語言(unified modeling language,UML),以組件圖的形式,描述了互換性模型內(nèi)部各種接口、組件的拓撲結(jié)構(gòu)。位于最頂層的是測試業(yè)務(wù)邏輯接口。位于模型底層的是各種測試儀器、板卡的驅(qū)動程序,包括儀器廠商提供的標(biāo)準(zhǔn)驅(qū)動程序、非標(biāo)準(zhǔn)驅(qū)動的API函數(shù)及其封裝組件等。
該模型的核心是在業(yè)務(wù)邏輯和具體儀器驅(qū)動程序之間增加了一個獨立的測試設(shè)備驅(qū)動器,并通過后者隔離了上下層的直接聯(lián)系,封裝了所有關(guān)于硬件的操作。測試業(yè)務(wù)邏輯程序只針對測試設(shè)備驅(qū)動接口進行開發(fā),使其具備良好的可移植性;當(dāng)測試設(shè)備升級或儀器替換時,只需重構(gòu)測試設(shè)備驅(qū)動組件,不必修改已有的軟件程序。測試設(shè)備驅(qū)動器包含了5個獨立的功能單元。
圖1 專用測試設(shè)備的互換性模型(組件圖)
1)測試需求接口集合:
通過對測試設(shè)備硬件需求的分類,針對各項測試需求,建立規(guī)范的需求接口,并將其匯總在一起,形成面向該類設(shè)備的、標(biāo)準(zhǔn)化的需求接口集合。例如,對于慣導(dǎo)、慣測等類型的被測產(chǎn)品,由于其數(shù)字化程度很高,因而在測試設(shè)備的硬件需求中,以各種類型的數(shù)字通訊需求為主;對于導(dǎo)航計算機類的被測產(chǎn)品,測試設(shè)備的硬件需求較為復(fù)雜,包括了數(shù)字通訊、模擬量、數(shù)字量、脈沖信號以及其它的特殊接口等。
這些接口本質(zhì)上是對該類測試設(shè)備所實現(xiàn)的測試需求的抽象,反應(yīng)的是該類設(shè)備硬件需要實現(xiàn)的系統(tǒng)級功能,與非標(biāo)準(zhǔn)儀器、嵌入式板卡的驅(qū)動接口相比,具有更好的普適性和穩(wěn)定性。
2)測試設(shè)備驅(qū)動接口:
測試需求接口集合描述了某類設(shè)備的全部需求,但實際上,每種測試設(shè)備并不需要實現(xiàn)全部功能。為此,建立獨立的測試設(shè)備驅(qū)動接口,通過對若干種需求接口的組合,描述了某個測試設(shè)備需要實現(xiàn)的各項功能,其目標(biāo)是將軟件需求層面的測試要求,映射為軟件設(shè)計層面的驅(qū)動接口定義。在測試設(shè)備驅(qū)動器中,采用外觀(Facade)模式[9],將驅(qū)動接口作為對外的唯一端口,提供了標(biāo)準(zhǔn)接口規(guī)范、交互機制,屏蔽驅(qū)動器內(nèi)部的具體實現(xiàn)。
3)測試設(shè)備驅(qū)動組件:
測試設(shè)備驅(qū)動組件是驅(qū)動接口的具體實現(xiàn),描述了某個實際測試設(shè)備是如何實現(xiàn)驅(qū)動接口中定義的各項需求。測試設(shè)備功能的實現(xiàn)依賴于集成的測試儀器、板卡以及電氣連接拓撲關(guān)系。該模型中,前者對應(yīng)的是測試設(shè)備驅(qū)動組件,后者保存在配置文件中。
4)測試設(shè)備配置文件:
配置文件采用XML文件形式,描述了測試設(shè)備的資源配置信息,包括各種儀器、板卡的資源描述、儀器的信號端口定義、內(nèi)部的電氣連接關(guān)系、設(shè)備的對外功能端口等。通過這些文件,將測試設(shè)備對外提供的各個功能項目映射到內(nèi)部儀器、板卡的端口和引腳上,從而將硬件資源配置信息與業(yè)務(wù)邏輯程序分離,提高了測試軟件開發(fā)的靈活性和移植性。
5)設(shè)備驅(qū)動創(chuàng)建組件:
該組件根據(jù)設(shè)備的資源配置信息,完成測試設(shè)備驅(qū)動組件的實例化操作,從而在測試業(yè)務(wù)邏輯與測試設(shè)備硬件建立關(guān)聯(lián)。
該組件使用了簡單類廠模式,根據(jù)測試設(shè)備的邏輯名稱,通過反射機制,動態(tài)創(chuàng)建驅(qū)動組件對象。利用運行時動態(tài)創(chuàng)建方式,可以將設(shè)備驅(qū)動組件的實例化操作延遲到軟件運行后進行,使測試軟件具有良好的擴展性,當(dāng)硬件儀器升級或替換時,只需在配置文件中修改驅(qū)動組件的信息,無需修改原有的測試程序。
該方法中,測試需求接口集合、測試設(shè)備驅(qū)動接口的設(shè)計、驅(qū)動組件開發(fā)是主要工作內(nèi)容。
在實際的工程應(yīng)用中,每種測試設(shè)備都是針對某個特定需求而開發(fā)的,這些需求在項目任務(wù)書、技術(shù)要求等文件中有明確的規(guī)定??梢酝ㄟ^對這些需求的匯總和分析,獲得該類設(shè)備的總體需求情況,進而抽象出對應(yīng)的需求接口。
以導(dǎo)航計算機測試設(shè)備的需求情況為例,雖然每種測試設(shè)備的硬件構(gòu)成都有差別,但仍然可以從更高層面上,總結(jié)出該類設(shè)備所具有的總體需求情況。這些硬件需求可以分為12類,其中,電源控制、串口通訊、模擬量控制和數(shù)字量控制是必選項;其他項目,如脈沖信號輸出、光纖陀螺集成測試、PWM信號采集、VF恒流源輸出、計數(shù)器信號控制、網(wǎng)絡(luò)通訊、CAN通訊、1553B總線通訊等為可選項,可根據(jù)實際的測試要求,靈活選擇。例如,在光纖陀螺測試中,必須提供光纖陀螺集成測試選項;在振梁加表測試中,需要不可逆計數(shù)器脈沖輸出控制;在含VF電路的產(chǎn)品測試時,需提供外部的恒流源控制功能等。
1)測試需求接口集合的設(shè)計:
針對需求分解中獲得的每項測試需求,建立獨立的需求接口,并提供規(guī)范的接口定義,代表了設(shè)備需要實現(xiàn)的一項獨立需求。在進行測試需求接口集合的設(shè)計時,主要關(guān)注以下兩點:
每個接口代表一個獨立的職責(zé),避免重復(fù)定義和功能混淆。例如,不可逆脈沖信號和頻標(biāo)信號在性質(zhì)上基本相同,多數(shù)測試設(shè)備也都是采用相同的程控儀器或嵌入式板卡實現(xiàn),但從需求角度分析,兩者職責(zé)完全不同,需要單獨定義。
接口定義中禁止出現(xiàn)硬件信息的內(nèi)容。例如,測試板卡的板卡號、端口號、通道號等內(nèi)容應(yīng)避免出現(xiàn)在接口函數(shù)中。應(yīng)從需求角度出發(fā),以被測產(chǎn)品編號、端口號等代替,并在配置文件中建立與具體硬件資源的映射信息。
2)測試設(shè)備驅(qū)動接口的設(shè)計:
測試設(shè)備的驅(qū)動接口定義了某個實際測試設(shè)備應(yīng)實現(xiàn)的硬件功能。從前面的分析可知,每種測試設(shè)備的實現(xiàn)功能是有限的,都是若干需求項的組合,因而測試設(shè)備的驅(qū)動接口可以看作是多個需求接口的集成。
在圖2中,使用UML組件圖的形式,描述了某種專用測試設(shè)備的驅(qū)動接口(忽略了必選的需求項)。該驅(qū)動接口包含了串口通訊、光纖陀螺集成測試、脈沖輸出測試和計數(shù)器信號控制等四個獨立的需求項,可以實現(xiàn)一些功能上相對簡單的導(dǎo)航計算機產(chǎn)品的測試。
圖2 測試設(shè)備驅(qū)動接口的設(shè)計(組件圖)
在圖2中,還提供了一個測試功能基礎(chǔ)接口,定義了最基本的操作內(nèi)容,如初始化、關(guān)閉、復(fù)位、運行狀態(tài)、事件的接收和發(fā)送等。所有特定項目的需求接口必須繼承該基礎(chǔ)接口,并通過后者,組合到測試設(shè)備驅(qū)動接口中,形成更復(fù)雜的、完整的測試設(shè)備驅(qū)動接口,同時,便于后者的功能擴展。
測試設(shè)備驅(qū)動組件是對測試設(shè)備驅(qū)動接口的實現(xiàn),描述了測試設(shè)備的具體實現(xiàn)方式。測試設(shè)備驅(qū)動組件通過調(diào)用對應(yīng)測試儀器、板卡的驅(qū)動程序,結(jié)合電氣關(guān)系配置文件,實現(xiàn)了測試設(shè)備驅(qū)動接口中定義的全部功能需求。
在工程項目中,一般將驅(qū)動組件的軟件開發(fā)和測試設(shè)備的硬件開發(fā)結(jié)合在一起,其過程如圖3所示。測試設(shè)備硬件設(shè)計是驅(qū)動接口設(shè)計的直接依據(jù),明確該測試設(shè)備需要實現(xiàn)的功能要求。硬件選型工作直接決定了在驅(qū)動組件開發(fā)時需要使用的儀器驅(qū)動程序,電氣關(guān)系配置文件中的內(nèi)容來源于硬件的電氣設(shè)計。最后,開發(fā)的設(shè)備驅(qū)動組件描述了測試設(shè)備是如何實現(xiàn)預(yù)定的功能,與設(shè)備的硬件開發(fā)相互匹配。
圖3 測試設(shè)備驅(qū)動組件的開發(fā)過程
導(dǎo)航計算機測試設(shè)備是一種典型的、用于電子產(chǎn)品測試的系列化專用設(shè)備。在該類測試軟件項目的開發(fā)中,通過測試設(shè)備驅(qū)動接口,為上層的業(yè)務(wù)邏輯程序提供了一個穩(wěn)定的開發(fā)基礎(chǔ),例如,對于電源控制而言,測試程序只需針對電源控制功能接口進行開發(fā),不必了解該功能是如何實現(xiàn)的。
同時,將對各種測試儀器、板卡的控制功能封裝到具體的實現(xiàn)組件中。例如,對于前文表1中提到的三個測試設(shè)備,分別建立各自的測試設(shè)備驅(qū)動組件。雖然它們的對外接口完全一致,測試程序都可自由調(diào)用,但組件內(nèi)部的具體實現(xiàn)卻完全不同。以“電源控制”功能為例:
1)設(shè)備1的電源控制:該設(shè)備的開發(fā)年代較早,使用了自研的電源輸出電路。在硬件上,通過數(shù)字IO板卡,控制繼電器的開閉,實現(xiàn)電源的通斷操作。在該設(shè)備驅(qū)動組件的內(nèi)部,本質(zhì)上是利用IO板卡的驅(qū)動函數(shù),實現(xiàn)電源輸出的間接控制。
2)設(shè)備2的電源控制:硬件上使用了標(biāo)準(zhǔn)的程控電源,在驅(qū)動組件開發(fā)時,可直接使用規(guī)范的IviDCPwr類驅(qū)動,或使用廠商提供的IVI專用驅(qū)動程序,實現(xiàn)電源輸出控制功能。
3)設(shè)備3的電源控制:硬件上使用了外置的程控電源。在驅(qū)動組件開發(fā)時,使用RS232串口,發(fā)送廠商提供的SCPI控制指令,實現(xiàn)電源輸出控制功能。
從中可以看出,該方法將測試儀器、板卡驅(qū)動程序的差異性信息封閉在驅(qū)動組件的內(nèi)部,并對外提供了統(tǒng)一的接口,當(dāng)測試程序在不同測試設(shè)備上移植時,只需調(diào)用不同的驅(qū)動組件;當(dāng)測試設(shè)備升級、改造后,只需調(diào)整驅(qū)動組件的內(nèi)部實現(xiàn),降低了對現(xiàn)有測試程序的影響。
在專用測試設(shè)備中,很多測試儀器、板卡的驅(qū)動程序不符合現(xiàn)有的標(biāo)準(zhǔn)和規(guī)范,為儀器互換和程序移植帶來了巨大的困難,為此,本文提出了一種針對專用測試設(shè)備的互換性實現(xiàn)方法。本方法將關(guān)注點放在了測試設(shè)備的系統(tǒng)需求上,屏蔽了不同的非標(biāo)儀器驅(qū)動在具體細節(jié)上的差異,為測試軟件開發(fā)建立了更加宏觀和抽象的需求接口。測試軟件的業(yè)務(wù)邏輯針對該接口開發(fā),使得測試程序具有良好的移植性。此外,建立了特定的測試設(shè)備驅(qū)動組件,用于封裝各種非標(biāo)準(zhǔn)驅(qū)動程序,當(dāng)硬件升級或改造時,其影響只限定在組件內(nèi)部,便于儀器互換。
該方法已經(jīng)在多個系列專用測試設(shè)備的軟件開發(fā)中得到了應(yīng)用,有效隔離了測試軟件中業(yè)務(wù)邏輯部分和底層硬件部分,使兩者相互獨立,降低了軟硬件間的直接耦合性,有效提高了專用測試設(shè)備的儀器互換性。