测试系统硬件驱动插件机制的设计与实现

古 平，石小江，彭仁强

(中国燃气涡轮研究院，四川 江油 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.