专用测试设备的互换性实现方法

秦振汉,林 渊,胡广明,郭双红

(航天科工惯性技术有限公司,北京 100074)

0 引言

仪器互换性是衡量测控系统的重要指标，也是测试软件设计和开发时面对的重点问题。提高互换性的目的是当测试设备仪器升级或替换后, 不会对现有的测试软件造成太大影响；同时便于已有测试程序向其他测试设备的移植[1]。目前，已经陆续推出了多种仪器互换标准、规范[2-5]，并在测控领域得到了广泛的应用。但在实际工程项目中，仍然存在大量的非标准仪器、板卡，这些仪器的驱动程序未遵循或未完全遵循现有的标准，而是使用厂商自定义的指令集、API函数,相互间无法兼容。由这些非标准仪器、板卡构成的专用测试设备，在测试软件开发中无法使用现有的互换性技术，当板卡或仪器进行升级或替换时，由于特定驱动程序的改变，经常导致现有的测试程序无法使用；同时，测试软件和硬件驱动程序直接相关，无法快速、方便地移植其它测试设备上，测试软件的可移植性很低。

为此，通过对开发实践的归纳和总结，本文提出了一种提高专用测试设备互换性的工程实现方法。该方法忽略了各种仪器或板卡的具体实现细节，将关注点放在更高一层的测试设备层面，通过对测试设备需要实现的测试需求的抽象，建立标准化的测试需求接口集合，并通过对这些接口的组合，建立特定的测试设备驱动接口。业务逻辑程序只依赖该接口，不涉及硬件的实现细节。同时，将测试仪器或板卡的具体操作封装在驱动组件内部，并与配置文件一起发布，描述了测试设备的实现细节。

通过这种方式，为测试软件的开发提供了规范的接口定义，业务逻辑面向接口进行开发，便于现有软件在不同测试设备上的移植；同时，将各种非标准仪器驱动对测试软件的影响控制在驱动组件内部，提高了测试设备的仪器互换性。

1 专用测试设备的仪器互换性方法

1.1 仪器互换性技术

目前常用的仪器互换性技术包括: SCPI互换、VPP互换、ATLAS语言规范、IVI-C、IVI-COM、IVI-MSS、IVI-Signal互换[2-5]等。这些技术可分为面向仪器的互换和面向信号的互换等两类[5]。其中，SCPI互换、VPP互换、IVI-C和IVI-COM互换等属于面向仪器的互换, 其基本思想是把同类仪器的操作封装成相同的接口，其函数名称、参数相同，主要解决同类仪器之间互换问题。但实际上随着仪器的功能、种类越来越多，已经很难对仪器进行明确的分类，也不能覆盖所有的测试仪器。面向信号的互换技术包括ATLAS语言规范、IVI-MSS、IVI-Signal互换等,其基本思想是按照仪器支持的信号功能对测试资源进行分类，相同的信号具有相同的函数接口。虽然测试程序可以面向信号方式实现，但是对各种物理仪器的操作仍然需要调用各种驱动程序来实现。

1.2 专用测试设备的硬件组成

在专用测试设备开发中，需要使用大量的PCI、CPCI嵌入式板卡和其他一些非标准仪器。这些仪器的驱动程序由不同厂商、在不同的时间开发，并没有遵守统一的标准或规范。有些测试仪器、板卡是针对特定需求而定制开发的，本身就没有可供参考的标准。

以导航计算机测试设备为例，这是一个由多种测试设备组成的系列化产品，用于各型导航计算机的测试，在产品研试、小批量试制和生产交付阶段中广泛应用。该类测试设备受功能需求、时间、成本、通用化、系列化等因素的影响，使用了很多的非标仪器和板卡。表1罗列了典型测试设备中几种常用仪器的选型情况。

表1 几种典型导航计算机测试设备的硬件构成

从表1的情况可知，除少数仪器(以斜体标识)外，大多数仪器、板卡的驱动程序都不是按照现有标准开发的。此外，有些专门定制的板卡，其类别已经很难划分，也无法采用面向信号方式描述。这种情况在专用测试设备中很常见，给互换性开发带来了很大的困难。

1.3 专用测试设备的互换性实现模型

针对这种情况，参考已有的研究成果[6-8]，结合实际工程实践，建立了如图1所示的专用测试设备的互换性模型。

图1使用统一建模语言(unified modeling language，UML)，以组件图的形式，描述了互换性模型内部各种接口、组件的拓扑结构。位于最顶层的是测试业务逻辑接口。位于模型底层的是各种测试仪器、板卡的驱动程序，包括仪器厂商提供的标准驱动程序、非标准驱动的API函数及其封装组件等。

该模型的核心是在业务逻辑和具体仪器驱动程序之间增加了一个独立的测试设备驱动器，并通过后者隔离了上下层的直接联系，封装了所有关于硬件的操作。测试业务逻辑程序只针对测试设备驱动接口进行开发，使其具备良好的可移植性；当测试设备升级或仪器替换时，只需重构测试设备驱动组件，不必修改已有的软件程序。测试设备驱动器包含了5个独立的功能单元。

图1 专用测试设备的互换性模型(组件图)

1)测试需求接口集合：

通过对测试设备硬件需求的分类，针对各项测试需求，建立规范的需求接口，并将其汇总在一起，形成面向该类设备的、标准化的需求接口集合。例如，对于惯导、惯测等类型的被测产品，由于其数字化程度很高，因而在测试设备的硬件需求中，以各种类型的数字通讯需求为主；对于导航计算机类的被测产品，测试设备的硬件需求较为复杂，包括了数字通讯、模拟量、数字量、脉冲信号以及其它的特殊接口等。

这些接口本质上是对该类测试设备所实现的测试需求的抽象，反应的是该类设备硬件需要实现的系统级功能，与非标准仪器、嵌入式板卡的驱动接口相比，具有更好的普适性和稳定性。

2)测试设备驱动接口：

测试需求接口集合描述了某类设备的全部需求，但实际上，每种测试设备并不需要实现全部功能。为此，建立独立的测试设备驱动接口，通过对若干种需求接口的组合，描述了某个测试设备需要实现的各项功能，其目标是将软件需求层面的测试要求，映射为软件设计层面的驱动接口定义。在测试设备驱动器中，采用外观(Facade)模式[9]，将驱动接口作为对外的唯一端口，提供了标准接口规范、交互机制，屏蔽驱动器内部的具体实现。

3)测试设备驱动组件：

测试设备驱动组件是驱动接口的具体实现，描述了某个实际测试设备是如何实现驱动接口中定义的各项需求。测试设备功能的实现依赖于集成的测试仪器、板卡以及电气连接拓扑关系。该模型中，前者对应的是测试设备驱动组件，后者保存在配置文件中。

4)测试设备配置文件：

配置文件采用XML文件形式，描述了测试设备的资源配置信息，包括各种仪器、板卡的资源描述、仪器的信号端口定义、内部的电气连接关系、设备的对外功能端口等。通过这些文件，将测试设备对外提供的各个功能项目映射到内部仪器、板卡的端口和引脚上，从而将硬件资源配置信息与业务逻辑程序分离，提高了测试软件开发的灵活性和移植性。

5)设备驱动创建组件：

该组件根据设备的资源配置信息，完成测试设备驱动组件的实例化操作，从而在测试业务逻辑与测试设备硬件建立关联。

该组件使用了简单类厂模式，根据测试设备的逻辑名称，通过反射机制，动态创建驱动组件对象。利用运行时动态创建方式，可以将设备驱动组件的实例化操作延迟到软件运行后进行，使测试软件具有良好的扩展性，当硬件仪器升级或替换时，只需在配置文件中修改驱动组件的信息，无需修改原有的测试程序。

2 互换性的设计与开发

该方法中，测试需求接口集合、测试设备驱动接口的设计、驱动组件开发是主要工作内容。

2.1 测试需求分解

在实际的工程应用中，每种测试设备都是针对某个特定需求而开发的，这些需求在项目任务书、技术要求等文件中有明确的规定。可以通过对这些需求的汇总和分析，获得该类设备的总体需求情况，进而抽象出对应的需求接口。

以导航计算机测试设备的需求情况为例，虽然每种测试设备的硬件构成都有差别，但仍然可以从更高层面上，总结出该类设备所具有的总体需求情况。这些硬件需求可以分为12类，其中，电源控制、串口通讯、模拟量控制和数字量控制是必选项；其他项目，如脉冲信号输出、光纤陀螺集成测试、PWM信号采集、VF恒流源输出、计数器信号控制、网络通讯、CAN通讯、1553B总线通讯等为可选项，可根据实际的测试要求，灵活选择。例如，在光纤陀螺测试中，必须提供光纤陀螺集成测试选项；在振梁加表测试中，需要不可逆计数器脉冲输出控制；在含VF电路的产品测试时，需提供外部的恒流源控制功能等。

2.2 接口设计

1)测试需求接口集合的设计：

针对需求分解中获得的每项测试需求，建立独立的需求接口，并提供规范的接口定义，代表了设备需要实现的一项独立需求。在进行测试需求接口集合的设计时，主要关注以下两点：

每个接口代表一个独立的职责，避免重复定义和功能混淆。例如，不可逆脉冲信号和频标信号在性质上基本相同，多数测试设备也都是采用相同的程控仪器或嵌入式板卡实现，但从需求角度分析，两者职责完全不同，需要单独定义。

接口定义中禁止出现硬件信息的内容。例如，测试板卡的板卡号、端口号、通道号等内容应避免出现在接口函数中。应从需求角度出发，以被测产品编号、端口号等代替，并在配置文件中建立与具体硬件资源的映射信息。

2)测试设备驱动接口的设计：

测试设备的驱动接口定义了某个实际测试设备应实现的硬件功能。从前面的分析可知，每种测试设备的实现功能是有限的，都是若干需求项的组合，因而测试设备的驱动接口可以看作是多个需求接口的集成。

在图2中，使用UML组件图的形式，描述了某种专用测试设备的驱动接口(忽略了必选的需求项)。该驱动接口包含了串口通讯、光纤陀螺集成测试、脉冲输出测试和计数器信号控制等四个独立的需求项，可以实现一些功能上相对简单的导航计算机产品的测试。

图2 测试设备驱动接口的设计(组件图)

在图2中，还提供了一个测试功能基础接口，定义了最基本的操作内容，如初始化、关闭、复位、运行状态、事件的接收和发送等。所有特定项目的需求接口必须继承该基础接口，并通过后者，组合到测试设备驱动接口中，形成更复杂的、完整的测试设备驱动接口，同时，便于后者的功能扩展。

2.3 测试设备驱动组件的开发

测试设备驱动组件是对测试设备驱动接口的实现，描述了测试设备的具体实现方式。测试设备驱动组件通过调用对应测试仪器、板卡的驱动程序，结合电气关系配置文件，实现了测试设备驱动接口中定义的全部功能需求。

在工程项目中，一般将驱动组件的软件开发和测试设备的硬件开发结合在一起，其过程如图3所示。测试设备硬件设计是驱动接口设计的直接依据，明确该测试设备需要实现的功能要求。硬件选型工作直接决定了在驱动组件开发时需要使用的仪器驱动程序，电气关系配置文件中的内容来源于硬件的电气设计。最后，开发的设备驱动组件描述了测试设备是如何实现预定的功能，与设备的硬件开发相互匹配。

图3 测试设备驱动组件的开发过程

3 在项目开发中的应用

导航计算机测试设备是一种典型的、用于电子产品测试的系列化专用设备。在该类测试软件项目的开发中，通过测试设备驱动接口，为上层的业务逻辑程序提供了一个稳定的开发基础，例如，对于电源控制而言，测试程序只需针对电源控制功能接口进行开发，不必了解该功能是如何实现的。

同时，将对各种测试仪器、板卡的控制功能封装到具体的实现组件中。例如，对于前文表1中提到的三个测试设备，分别建立各自的测试设备驱动组件。虽然它们的对外接口完全一致，测试程序都可自由调用，但组件内部的具体实现却完全不同。以“电源控制”功能为例：

1)设备1的电源控制：该设备的开发年代较早，使用了自研的电源输出电路。在硬件上，通过数字IO板卡，控制继电器的开闭，实现电源的通断操作。在该设备驱动组件的内部，本质上是利用IO板卡的驱动函数，实现电源输出的间接控制。

2)设备2的电源控制：硬件上使用了标准的程控电源，在驱动组件开发时，可直接使用规范的IviDCPwr类驱动，或使用厂商提供的IVI专用驱动程序，实现电源输出控制功能。

3)设备3的电源控制：硬件上使用了外置的程控电源。在驱动组件开发时，使用RS232串口，发送厂商提供的SCPI控制指令，实现电源输出控制功能。

从中可以看出，该方法将测试仪器、板卡驱动程序的差异性信息封闭在驱动组件的内部，并对外提供了统一的接口，当测试程序在不同测试设备上移植时，只需调用不同的驱动组件；当测试设备升级、改造后，只需调整驱动组件的内部实现，降低了对现有测试程序的影响。

4 结束语

在专用测试设备中，很多测试仪器、板卡的驱动程序不符合现有的标准和规范，为仪器互换和程序移植带来了巨大的困难，为此，本文提出了一种针对专用测试设备的互换性实现方法。本方法将关注点放在了测试设备的系统需求上，屏蔽了不同的非标仪器驱动在具体细节上的差异，为测试软件开发建立了更加宏观和抽象的需求接口。测试软件的业务逻辑针对该接口开发，使得测试程序具有良好的移植性。此外，建立了特定的测试设备驱动组件，用于封装各种非标准驱动程序，当硬件升级或改造时，其影响只限定在组件内部，便于仪器互换。

该方法已经在多个系列专用测试设备的软件开发中得到了应用，有效隔离了测试软件中业务逻辑部分和底层硬件部分，使两者相互独立，降低了软硬件间的直接耦合性，有效提高了专用测试设备的仪器互换性。