虚拟仪器测试环境软件总线体系结构

图1 虚拟仪器测试环境标准框架

　　在整个标准体系中，根据产品测试的特征，划分为两个层次的框架，即信息框架和系统框架，所有相关的组件标准以即插即用的功能模块形式挂在框架软总线上。
　　产品测试过程中的各种信息处理围绕着信息框架展开，分别包括测试需求建模数据、测试程序文档、机内测试数据、诊断和维护数据、仪器资源数据和数据交换格式数据等。其关键是IEEE 1226标准中定义的核心测试信息模型（Core Test Information Model），充分描述了测试、测试说明、测试需求和其它的广域测试领域的信息实体。各个组件标准都是基于CTIM的，并根据各自的特点完成对CTIM的扩展，从而将其定制到不同应用领域。
　　具体的测试实现则围绕着系统框架展开，包括各种的资源管理服务、运行时服务、仪器驱动、诊断处理服务等。
　　系统框架负责向信息框架提供信息来源，是信息的提供者。而信息框架根据产品测试要求，向系统框架发出信息采集命令，并接收和处理信息。
　　所谓框架实质上是为简化特殊应用领域的应用开发和系统管理而设计的软件环境。从另外一个视角看这个标准框架，框架在软件层次中是一种中间件，它位于操作系统之上，具体的测试应用之下。图2显示了ABBET测试基本框架（Test Foundation Framework）中的标准的综合集。

图2 ABBET测试基础标准框架

　　标准化框架允许测试应用和工具能够在实现于ABBET框架服务之上的异构平台中得到支持。这些标准围绕表示测试主体、测试资源和测试环境的三个轴进行组织。
　　图中水平轴所表示的测试主体标准支持测试主体信息的获取和重用。测试主体信息捕获对测试主体设计和测试需求的说明，这些说明可以避免在初期开发、维护和测试应用的重驻过程中进行二次开发。测试主体信息也包括诊断知识，可在测试过程中被访问。
　　垂直轴所表示的测试资源标准应用于测试资源和信息。测试资源控制标准支持对仪器配置和数据获取等系统服务的访问。测试资源信息标准支持对测试应用资源需求和测试仪器能力进行规范。这些标准支持调整测试应用，以适应测试设备配置的修改。
　　斜轴所表示的环境相关标准，支持测试应用在异构测试环境之间的互换和重驻。测试信息以一种中立的、与具体实现无关的格式进行交换，这种格式对于数据导入、导出服务很适合。
　　二、VITE实现体系结构
　　开放式虚拟仪器测试环境的体系结构中包含了多种标准的开放式软件接口关系。软件功能模块通过这些接口实现信息交换，这些带有标准接口的功能模块组成了测试基础框架。
　　VITE的实现以面向对象的组件为基础，按照信息框架和系统框架的原则，设计实现了若干个功能组件。具体结构见图3。

图3 VITE组成结构

　　组件是一种定义良好的独立可重用的二进制代码，它可以是一些功能模块、被封装的对象类、软件框架、软件系统模型等。目前基于对象的组件软件体系结构中的“组件”是指可方便地插入到语言、工具、操作系统、网络软件系统中的二进制形式的代码和数据。
　　软总线又叫对象总线或ORB(对象请求代理)，其目的是为组件间或组件使用者与组件提供者之间提供透明的通信通道。图中的应用执行、诊断显示、测试系统等组件就是挂接在软总线上的“软件集成电路(IC)”。
　　软总线是联结应用程序、各种对象、服务、对象工具集的核心，能够把各个组件对象元素有序地分割开来，用以实现分布式的软件集成和应用上的即插即用。它包括两个两个层次的关系：1）．对象方法、服务的“定义” 与它们的“实现”之间的关系。通过接口定义语言 OMG IDL 我们可以获得规范、通用的对象方法、服务定义。借助软总线，这些定义可以在任何编程语言、代码模块中真正实现，这种分割有助于进行具体软件编码互换，编程语言互换以及版本互换。2）．请求“客户”与响应“服务器”之间的关系。客户对其它对象方法、服务的请求并不直接传递给被请求服务器，而是转交给软总线，由总线监察服务器的位置、状态，并决定服务绑定的方式，这种关系有助于对分布式对象进行跨平台、跨协议的逻辑集成。
　　这两种关系能够保证组件通过总线进行通信，解决组件之间的互操作问题。每个组件通过组件通信单元（也称适配器）与总线连接，适配器组件解决互不相识的组件之间的互操作和数据交换问题。从适配器送往总线的数据组件对象能被任一其它适配器自动识别，而且数据组件对象安装期间可由安装人员进行适当的调整从而改变服务组件的功能和结构，以适应新的要求。用户界面组件提供表示服务，服务组件提供功能服务。
　　结合第2节描述的VITE标准体系结构划分和测试主体、测试资源、测试环境三者之间的关系，整个VITE的实现分为五个概念层。
　　第1层为测试信息层，主要对被测产品进行描述，以取得产品设计和维护试验的有关信息，以及其测试的特殊需求。图3中的模型编辑组件主要完成这一层的功能。
　　第2层为测试需求和策略层，提供UUT(被测件)的测试需求、测试模式和诊断知识的标准信息实体，其目的是产生高效的测试程序和可靠的数据。图3中的应用执行组件、诊断引擎组件、数据库引擎组件等主要完成这一层的功能。
　　第3层为用户应用程序层，主要用于帮助开发TPS程序，定义了与测试执行对应的操作接口，测试执行包括测试选择、测试顺序选择、诊断交互、访问用户接口部件以及访问数据日志和文件操作。图3中的应用执行组件、诊断显示组件等主要完成这一层的功能。
　　第4层为测试资源管理层，提供了用于全面管理测试系统资源的基本接口，支持在某一特定ATE条件下执行独立的ATE测试的能力，其目的是允许不同厂商制造的仪器和不同种类的仪器可用于同一测试程序以完成各自的功能。图3中的COTS测试语言组件主要完成这一层的功能。
　　第5层为仪器驱动(控制)层。该层主要提供了ATE可利用的各类总线标准和仪器接口，如IEEE488、SCPI、VISA、IVI等等。图3中的COTS仪器驱动组件主要完成这一层的功能。
　　三、VITE核心信息模型结构
　　VITE的信息框架的基本信息模型是基于核心信息模型结构CTIM的，其目标是描述一个或多个产品的测试，提供在不同系统间交换测试信息的途径。其描述可以是与测试器无关的，这样可以支持不同平台和环境之间的测试重用。
　　核心测试信息模型是一种描述测试行为的信息模型，它必须具有下面的功能特征：
　　a) 描述预期的产品行为特性
　　b) 定义测试需求
　　c) 定义资源能力和需求
　　d) 定义测试策略的行为
　　e) 引导系统诊断
　　CTIM模型中有五个实体：
　　a)位置(Location)：位置捕获事件发生的地点。在当前模型中位置没有被进一步定义，在将来与产品信息的绑定中会进一步定义。
　　b)行为(Behavior)：行为捕获事件发生的时间。用来标识事件发生的时间间隔，由其开始（start）和结束（stop）属性定义。
　　c)信号(Signal)：信号捕获发生的事件。信号的类型包括面向信号的符号、以及其它的标准编程类型(比如整数、实数或布尔类型)。
　　d)约束(Constraint)：约束定义了约束或限制信号取值范围的规则。
　　e)时间(Time)：模型中的时间只是用来支持行为实体的定义。它是变量(variable，下面将定义)实体的子类，用来定义行为实体的开始(start)和结束(stop)属性的类型。
　　图4  VITE的核心测试信息模型
　　本文上节所述的各个信息组件都是基于CTIM的，或者是对CTIM的扩展。所有组件能够在CTIM的基础上补充了进一步的细节，从而将其定制到不同测试应用领域。
　　四、可互换虚拟仪器IVI模型
　　在系统框架的引导下，VITE的仪器驱动按照标准体系的要求，采用IVI（Interchangeable Virtual Instruments）模型。IVI模型是IVI基金会在VPP（VXI Plug&Play）技术基础上制定的一种驱动器设计标准。它通过定义类驱动器和驱动器实现了部分通用仪器之间的互换，缩短了程序的开发时间，提高了系统的运行性能。
　　IVI标准的目的是允许用户把标准的IVI组件集成到不同的软件、硬件系统中。它支持各种接口，包括GPIB、VXI、PXI、Serial、USB、Ethernet、Firewire和PC plug-in等，允许同类仪器（可带不同接口）互换。该技术的采用能够支持仪器互换，降低系统成本，改进系统运行性能和配置能力。
　　IVI模型采用了IVI-COM通信引擎的组件，能够保证仪器的动态互换。应用程序调用IVI的逻辑名，由引擎负责与配置库的逻辑名进行匹配，连接实际的物理仪器。
　　因此，在广泛收集测试系统的具体应用需求的信息下，遵循IVI标准，结各类通用测试仪器的使用情况，以面向对象的实现方法，建立各种IVI仪器类，封装仪器的属性、方法和事件，并能够继承和重构。实现不用修改测试程序的测试仪器的更换。只要测试仪器的功能相同就可以实现不用修改测试程序的测试仪器的互换。

　　虚拟仪器测试环境的软总线体系结构融合了测试工程项目管理要素（维修性论证、测试需求分析、诊断能力分配与设计、系统综合与试验、测试能力成熟度等）、嵌入式测试要素（BIT/BITE）、外部测试要素（维修等级、自动测试设备、测试程序集、人员培训、数据库、技术信息收集与分析、后勤技术保障）等一系列标准。在VITE平台的建设上，充分保证了：一是以测试需求分析为基础，二是贯彻综合诊断信息支持系统（IDSS）的思想，三是严格执行标准化程序，遵循和采用相关的国际和标准。这样的思路和方法使得我们在构造通用测试平台时获益匪浅。