当今技术的发展，日新月异。由此导致测试设备的淘汰影响着飞行器、汽车以及军用等测试行业。这些系统的测试在TPS上投入巨大，而且随着仪器的更新，将导致TPS的升级与重新编写，这又将会使投入进一步加大。人们早就试图解决仪器的互换性问题，早期MATE计划、ATLAS和后来的DAD计划都是不错的想法，特别是他们还提出了面向信号的概念，这些概念现在仍在使用。但是，最终他们失败了。因为这些政府项目，开销巨大、而且不能与技术的发展同步<2>。

解决仪器互换问题必须走的标准化道路。1990年，SCPI联盟试图标准化所有仪器的ASCI命令，开创了通用仪器类的概念。但是这时正值仪器驱动技术流行，以至于没有多少用户真正了解到SCPI的优越性<2>。

90年代中期，VPP驱动器出现了。它开发了仪器软面板，解决了不同厂商仪器驱动器之间的互操作性问题，开发了VISA传输层，但是，他们从来就没有解决仪器的互换性问题。而且，他们受到了后来微软COM技术的威胁。

这些标准都提出了一些新的概念或想法，促进了仪器互换性的发展，但是这些标准化家族也都有各自的优缺点。要解决仪器的互换性必须结合以前的成功经验，引进最新技术和采用复杂的体系结构，并考虑将来的发展<2>。直到IVI技术的出现，才使得仪器互换技术得到了较好的实现。

　IVI规范和体系结构为了提高仪器驱动程序的执行性能和实现仪器的互换性，1998年由9个公司成立了IVI（interchang2 eable virtual instrument）基金会，在VXI2PNP技术的基础上为仪器驱动程序制定新的编程接口，在VISA标准驱动程序上插入VXI2PNP框架结构和类驱动程序。

IVI一经提出就得到了一些仪器生产厂商的响应，目前已经发布了9大类仪器规范。美国国家仪器公司（简称NI）作为IVI的系统联盟之一，积极响应IVI的号召，并开发了基于虚拟仪器软件平台的IVI驱动程序库和配置环境。IVI技术的发展也引起了美国国防部（DoD）的兴趣，并向其提出了制定包括源和测试装置在内的光电仪器类的需求。下一代测试（NText）工作组也将IVI作为其关键技术之一<2>。

IVI体系结构由IVI仪器类驱动器、IVI具体仪器驱动程序、IVI引擎、IVI配置实用程序和IVI配置信息文件五部分组成，如所示。测试程序（TP）调用仪器类驱动器，仪器类驱动程序再调用具体仪器驱动程序来控制真实仪器。IVI引擎通过控制仪器的读写属性，来监测IVI驱动程序，实现状态缓存与参数验证等功能。此外，实现仪器的互换还必须借助配置工具，进行必要的配置。

IVI的缺点IVI技术是当前最为流行的仪器互换技术，而且该技术也正处在发展当中。但是，IVI技术的一些固有缺陷也影响了仪器的互换性和实际应用。

首先，虽然IVI在过去的几年里取得了巨大的进步，但是目前只发布了9个仪器类，这只是众多仪器类中的一小部分<3>。另外，只有相对较少的硬件开发商支持IVI驱动器<3>，这种限制成为了测试系统中采用IVI的主要障碍。虽然在IVI的基础上又定义了IVI2MSS和IVI信号接口以支持更高层的仪器互换，但是IVI的固有缺陷也影响了它的灵活性。

其次，所有仪器的功能不能完全相同，因此，不可能建立一个单一的编程接口满足不同仪器的所有要求。为了适应这一需求，IVI基金会将仪器类规范分成基本功能和扩展功能。前者定义了同类仪器中绝大多数仪器所共有的能力和属性。后者则是更多地体现了每类仪器的许多特殊功能和属性。但是，该结构中的扩展功能影响了仪器互换性的实现。还有，NI作为IVI的积极响应者，开发了基于虚拟仪器软件平台的IVI驱动程序库和配置环境MAX.在MAX中需要配置的有四项： Devices、Instrument Drivers、Virtual Instruments、Logical Names.

虽然IVI宣称自己是一个开放式体系结构，但是其所提供的配置功能还很有限。仪器驱动器的接口由IVI规范保证，没有在配置环境中配置，对用户来说少了灵活性。

基于开发式系统的仪器互换性实现为了克服IVI的缺点，并继承其优点以支持更广泛的仪器互换性，本文提出了一种基于开放式体系结构的实现仪器互换性的方法，如所示。该体系结构由四部分组成：面向信号仪器驱动器、资源管理器、测试资源配置工具和模型库组成。仪器驱动器负责真实仪器的驱动，仪器驱动器的接口采用面向信号的定义方法，为实现不同仪器同类信号之间的互换奠定了基础；资源管理器负责将TPS的信号需求映射到具体的仪器及仪器驱动器接口，并对仪器驱动器进行调度；资源配置工具负责ATE测试资源的修改与维护；模型库保存系统的ATE测试资源信息，为资源管理器的资源匹配与仪器驱动器自动调用提供依据。其中设备模型、配置模型和适配器模型为ATE硬件测试资源的描述，仪器驱动器模型为面向信号仪器驱动器接口的描述。

驱动器所谓仪器驱动器就是一组用于控制可编程仪器的软件模块。传统的仪器驱动器是由仪器开发商根据特定的仪器开发的，用以控制相应仪器的配置、读写或触发的一组函数集。仪器驱动器的出现极大的减轻了测试应用开发的难度，开发人员不必去学习每一个仪器的编程协议，简化了仪器控制，减少了测试用的开发周期。

为了实现仪器驱动器接口的面向信号和现有仪器驱动器的重用，设计了仪器驱动器的结构如所示。每个仪器驱动器包含如下两种接口： IDriver接口和信号接口。其中每个仪器都应当继承和实现IDriver接口，它负责仪器的初始化、自检和基本的设置工作；信号接口是一个标准，不同仪器实现的相同信号功能应该具有相同的信号接口，这样就可以实现不同仪器之间信号接口的互换，而不仅仅是仪器之间的互换。为了利用已有的仪器驱动器，可以采用包容和聚合等方法进行复用。

所有的面向信号的仪器驱动器都采用COM实现。COM软构件是一种接口定义良好、独立可重用的二进制代码，软构件的典型特征是接口特性、封装特性和重用性。此外，还具有多线程安全、数据共享机制、多平台支持和便于版本升级等固有的特性，可以极大地提高软件的性能及通用性和维护性<5>。

测试资源信息模型通常ATE测试资源信息模型包含三个部分，分别为：设备模型（DM）、适配器模型（AM）和配置模型（CM） ，它完整地描述了ATE硬件资源的信息以及资源之间的配置连接关系。其中，设备模型主要描述ATE设备的标识及其性能；适配器模型描述ATE接口连接器之间、UUT接口连接器之间、ATE接口连接器与UUT接口连接器之间的连接关系；配置模型是ATE的逻辑模型，它描述了在该测试环境下设备之间的相互连接和通信<6>。该模型框架最先由ARINC提出，后来为IEEE所采用，并在IEEE Std 99321997中用TEDL语言进行了描述。http://www.grainyq.com