測試系統硬件驅動插件機制的設計與實現

古 平，石小江，彭仁強

(中國燃氣渦輪研究院，四川 江油 621703)

1 引言

測試系統最主要的功能是采集被測對象的被測參數[1]。以往的測試程序，往往把所有的測試參數、儀器程控指令、測試結果和分析處理結果都放在測試系統軟件主體(平臺)中，而測試系統由于所選硬件配置的不同，相應驅動程序就各不一樣，一旦硬件有所變化，就必須更改測試系統軟件主體(平臺)，否則測試系統就不能正常運行，這樣就造成測試系統的靈活性、易用性、可靠性、可維護性、可擴充性、可移植性很差。若能把不同的驅動程序按其功能劃分，定義統一的接口，使其功能模塊化、插件化，組成通用插件庫，那么在測試系統集成應用時，就可根據所選硬件類型調用相應的驅動程序插件，做到即插即用，使測試系統軟件主體(平臺)更加規范、靈活，同時也將大大縮短軟件開發時間，便于后期的軟件維護。

2 插件機制方案設計

測試系統硬件驅動插件是連接軟、硬件和獲得前端采集信號的橋梁，要構建通用的、可靈活配置的、模塊化的硬件驅動插件程序，就應該具有一個開放式的結構和標準接口，同時還要考慮系統功能的可擴充性和技術的可延續性。作為一個完備的硬件驅動插件架構體系設計，不僅要包括硬件驅動插件的設計，還應該包括測試系統平臺的設計。平臺的功能通常包括測試系統軟件的核心功能和硬件驅動插件的處理功能，而硬件驅動插件通常是用來對測試系統使用到的硬件采集功能，按照定義的標準接口進行封裝，然后集中管理。平臺需要通過插件接口調用插件所實現的采集功能，讀取前端的采集信號等。本文僅對硬件驅動插件機制進行設計和實現，硬件和測試系統平臺軟件都不在此討論。硬件驅動插件和整個測試系統的關系如圖1所示。

2.1 驅動插件的創建和加載

硬件驅動是控制測試儀器I/O接口及其相關功能的規范，是計算機與儀器之間的軟件層連接，一般由設備廠商提供給用戶，是一套可調用的函數或指令集，實現對測試儀器的程序控制，完成對某一特定測試儀器的控制和通訊。每個測試儀器都有相應的驅動程序或通訊協議。通過在廠商提供的驅動程序或通訊協議的基礎上進行開發和封裝，將插件程序需要開放的屬性、方法、實現等定義出來，制定統一的數據結構和通訊協議，通過接口的方式提供給平臺程序使用。驅動程序的插件庫根據硬件類型必須是可加載、修改和擴展的。若用戶購置了新的硬件測試設備(儀器)，而硬件驅動庫中沒有對應的驅動程序，可按照系統制定的統一數據結構和通訊協議，開發對應的新硬件驅動插件，然后再將驅動插件加載到系統插件庫并保存，即可供用戶使用。開發和加載驅動插件過程如圖2所示。

圖1 測試系統總體結構圖Fig.1 The structure of measurement system

驅動插件加載實例如圖3所示，圖中“驅動動態庫”是二次開發封裝的插件庫，“相關文件”就是硬件供應商提供的驅動庫文件。

圖2 驅動插件加載過程Fig.2 The loading process of the plug-in of driver

圖3 驅動插件加載實例Fig.3 The loading instance of the plug-in of driver

2.2 驅動插件的數據結構

要做到通用，就必須具備統一的規范和標準，并且在開發硬件驅動插件程序時嚴格遵守。

不同的設備應有不同的設備ID，以區分不同的設備類型(如 DSA、華太 VXI、縱橫 VXI等)，不同設備要有各自的設備名稱、該設備所包含的所有采集板卡類型、以及實際擁有的板卡類型數。同樣，每一種硬件板卡類型都應有一個唯一區別的ID，以區分不同的板卡類型；每種采集板卡對應的采集通道數固定。根據設備ID和采集板卡ID，系統即可確定采用何種驅動程序來向指定的硬件發指令，用戶則可得到指定設備中指定采集板卡的通道數和各通道的采集數據。采集設備及板卡的數據結構層次見圖4。

圖4 采集設備及板卡數據結構層次Fig.4 The data structure tree of acquiring device and card

下面給出部分統一的數據結構內容項并加以概要說明(C++語言)：

typedef struct{

int nCardID; //板卡類型代碼

char ame[24]; //板卡類型名稱

int nChNums; //板卡類型通道數

}CARDTYPE; //硬件板卡類型結構

typedef struct{

int nDeviceID; //設備代碼

char DeviceName[24];//設備名稱

int nCardTypeNums;//設備板卡類型數

CARDTYPE CardType[CARD_TYPE_NUMS];

//板卡類型

}DEVICEINFO; //硬件設備信息結構

3 驅動插件的應用

3.1 硬件配置

用戶應用時，根據設備采集系統硬件配置類型，從驅動程序插件庫中選擇與之對應的插件，并設置相應的屬性，即完成硬件驅動配置。系統通過硬件驅動插件訪問設備的驅動程序，向硬件設備(儀器)發出一系列指令，就可得到對應硬件設備(儀器)的采集數據。若硬件類型發生改變，只需改變硬件驅動配置即可，用戶不必修改平臺軟件的源程序就能實現硬件設備(儀器)的即插即用。應用示例見圖5。

圖5 硬件配置應用示例Fig.5 The applied demonstration of hardware configuration

圖5 中，左邊為硬件驅動模塊插件庫列表，列出了已加載硬件驅動插件類型；右邊為已配置完成的驅動模塊程序插件組合。如某一測試系統的硬件由VXI、DSA和PSI組成，其中VXI由一塊16015S卡和一塊JV53124卡組成；DSA由一個3017模塊組成；PSI由一個9816模塊組成。用戶在配置測試系統硬件時，只需在左邊驅動程序插件庫中選擇與之對應的插件，放入右邊的列表中，并設置相應的屬性即可完成驅動配置。插件屬性設置實例見圖6。

圖6 插件屬性設置實例Fig.6 The setup instance of the property of plug-in

用戶分別設置采集卡所在的設備編號(機箱號)、采集卡在指定設備中的位置(槽號)、采集數據的平均遍數、采樣率、通道類型、增益、量程等參數，確定后，系統將保存用戶的設置，并按用戶的設置對硬件設備進行初始化，完成硬件系統準備工作。

3.2 生成掃描表

在完成硬件驅動配置后，系統根據其配置的各采集卡的通道數，自動生成一有序的物理通道掃描表，用戶可根據此表選擇本次試驗中用到的物理通道，按用戶習慣排列組合成一適應用戶習慣的邏輯通道表，當然，也可以選擇其硬件配置中所有物理通道。在此邏輯通道表中，用戶還可定義一些其它的非物理通道的參數，如性能計算通道，邏輯通道表數據結構部分內容項如下：

typedef struct{

……

short PhyNo; //物理通道編號

short PrgGain; //程控增益

shortEuTabNo; //工程單位轉換類型

char PhyAddr[40]; //物理通道標示

A-aa-bb-xx

char ChName[32]; //通道名稱[英文符號]

char ChName_Std[16];//發動機標準名稱

char EngUnit[16]; //工程單位

char Range[16]; //信號量程

char LineNum[16]; //管線號

char SensorNum[16];//傳感器編號

char Remark[40]; //通道注釋

}CHANNELDEFINE; //通道定義信息表

其中，與硬件設備密切相關項是“物理通道標示(PhyAddr)”，它標示該邏輯通道項與實際硬件設備通道的聯系，包含有與硬件相關的物理信息，用于硬件系統識別，也是區分非物理通道的標示。系統運行時，通過“物理通道標示(PhyAddr)”獲得硬件系統對應通道的信號數據。圖7是編輯完成的部分邏輯通道表格式實例。圖中1～4項為物理通道，5、6項為計算通道(計算通道中的數據由系統通過一系列計算后得到，計算中一般都要用到一些物理通道中的數據)。

圖7 部分邏輯通道表格式實例Fig.7 Part of the format instance of logic channels

4 系統運行流程

測試系統平臺軟件在運行時，首先根據裝入的通道表對物理通道進行采集設備及板卡分類，然后根據不同的采集設備和板卡，從系統驅動插件庫中裝入對應的驅動插件，并執行采集設備初始化。數據采集開始后，平臺軟件只需根據不同的采集設備和板卡調用驅動插件采集接口執行數據采集即可。整個測試系統插件調用流程如圖8所示。

5 結束語

本文設計并實現了一種測試系統驅動程序插件機制的實現方案，為測試系統驅動插件標準化提供了一個參考；此方案可以進一步擴充，實現更為靈活的實現方案。

測試系統硬件驅動的插件化使測試系統能夠做到通用化、模塊化、智能化、標準化，可徹底改變現有測試系統標準化程度低、功能單一、品種繁多、可維護性及保障性差的現狀。該設計現已在實際數據采集系統中得到推廣和應用，實踐表明，采用硬件驅動插件技術極大地提高了測試系統的開發效率，解決了測試系統的通用化問題。

圖8 測試系統插件調用流程圖Fig.8 The flow chart of plug-in in measurement system

[1]張寶誠.航空發動機試驗和測試技術[M].北京：航空航天大學出版社，2005.