传统自动测试系统缺乏通用性，最根本的解决方法是标准化。本文以ABBET（A BroadBased Environment for Test）标准为主，与ATS（AutomaTIc Test System）相关的其他国际标准为辅，采用符合标准描述的软件层次结构，使用COM组件和CORBA等软件设计技术，开发了面向信号的通用自动测试系统软件平台。采用基于国际标准ATS开发模式，一方面可以使面向信号的测试最大限度地实现仪器无关性和TPS（Test Program Set）通用性；另一方面这种开发模式简化了软件系统架构难度，提高系统的可靠性和兼容性，对外部诊断方法提供了统一的接口。
随着电子科学、材料科学等技术的飞速发展，航空航天设备、军用武器系统等高技术产品的复杂程度日益提高，传统的人工检测维护手段已经无法满足现代化装备的支持保障要求，ATS（自动测试系统）正逐步成为复杂系统与设备可靠运行的必要保证。
然而，我国目前尚无统一的测试技术体制和管理体制，也没有需要强制执行的测试软件体系标准。各种软件采用的数据结构不相同，系统模型千差万别，带来测试软件系统繁多的种类和低水平的重复研制。另外，测试软件运行环境不规范，使用的测试语言不统一或版本各异，导致系统测试软件不通用，造成开发周期长、重复开发、移植性差、交换能力弱等缺陷，在很大程度上影响了用户对其的掌握和使用。以上因素使得测试系统软件平台的通用化、标准化、模块化、系列化方面与国际水平差距很大，成为制约我国自动测试系统发展的首要因素。
本文重点研究了测试泛环境（ABBET）标准体系结构和实现软件平台通用性的关键技术，将ABBET定义的软件体系框架结构细化为5个可操作的软件层次（测试策略与需求层、测试程序层、资源管理层、仪器控制层、硬件层），利用每层相关标准分别开发其功能，实现层次间通信，最终开发出面向信号的通用自动测试软件平台。
1 测试相关国际标准概述
IEEE 1226 ABBET标准是一种软件体系结构规范，使按照该体系结构搭建起来的软件平台之间进行标准化的数据交换和相互操作。ABBET 对测试软件作了重点描述和规范，从信息建模的角度对测试信息进行形式化描述，消除了层次间测试信息移植、共享和应用的障碍。在软件设计上，强调系统重构或重组，能够根据被测对象或测试流程的不同而动态地进行重组，降低系统重组的代价。但是ABBET标准仅仅提出了ATS框架并描述了测试开发过程中各个层次之间的关系，在具体应用上如何实现这些层次的功能，实现一个完整的面向信号的自动测试系统，则需要设计者自行开发。
IEEE 1226.3和IVI仪器驱动规范描述如何最大限度地实现仪器互换性。
IEEE 1641标准提供了基于COM技术实现的信号描述与控制的能力，使得用户可以选择任意支持COM的开发平台与程序设计语言，而且能够很方便地实现测试程序的可移植。
IEEE 1671提供了一个开放的信息传输的标准，使得信息可以在不同测试仪器的测试程序之间传输，为TPS可移植与互操作、仪器可互换提供了便利条件。
IEEE 1232标准定义了ATS故障诊断服务接口。它提供了基本诊断服务，同时允许各种诊断方法添加到ATS中去，大大提高了ATS故障诊断水平。
2 测试平台软件架构
2.1 ABBET结构层次
ABBET结构由基础结构中的单一类别创建的类别集合所构成。这个基础提供了基础类和主要类的参考结构。这可以被指定在不同的层次创建通用测试环境（框架结构）或专用测试应用程序。
ABBET标准的体系结构分为3个层次：基础框架结构、扩展框架结构和应用。
基础框架的组织类似于一种接口的集合，其中每个接口与一个或多个ABBET组件标准相关，或者与IEEE或其他公认的组织发布的行业标准相关。定义了适合某个产品系生命周期内不同阶段相适应的基础接口。
一个TAF是一个可再用类别集合，来完成一个特定应用领域的要求。每个TAF服务于测试主题中的特定类别、技术、资源或需求。扩展框架就是由一个或多个这样的应用框架（TAF）组成。
ABBET提供从开发工具和TAF直接访问应用。一个应用可能使用一个或多个框架来提供到执行应用的类的访问。图1显示了ABBET结构层次，图2说明了根据与ABBET 组件标准有关的操作、功能以及组织进行划分的ABBET体系结构。
图1 ABBET结构层次 图2 ABBET体系结构
表1列举了测试泛环境的分层模型及每层需要用到的设计和测试标准。
表1 测试泛环境分层测试标准
2.2 测试平台软件结构
要实现通用ATS，则要求对资源的需求描述、虚拟资源的模型，以及对真实资源的驱动均基于信号接口，要摒弃驱动基于仪器的做法。TPS的可移植性和仪器可互换性的关键在于驱动模型的构造。
使用面向信号的驱动组件，当虚拟资源映射成真实信号时，仪器暴露给软件系统的是信号接口，而不是具体仪器。ABBET采用TFF信号模型描述测试需求，与具体测试系统无关。
图3显示了基于TFF信号模型的面向信号测试系统软件平台结构。
图3 软件平台结构
测试策略和需求层用于用户配置测试信息，如测试需求、测试策略。
测试程序层完成测试流程设计，并从测试需求和测试流程转换为测试代码。TFF信号模型组件库为不同编程开发环境的TPS开发提供信号模型。
资源管理层完成虚拟资源到实际资源的映射，执行具体的测试流程。编程语言接口将各种编程语言表示的测试信号资源需求形式变换成虚拟资源。资源模型库用来具体资源建模。驱动组件对驱动实际资源。
仪器控制层全面遵守IVI仪器驱动规范，利用IVICOM技术，驱动实际测试仪器。
3 关键技术讨论
3.1 RTS运行机制
RTS是资源管理层中核心组件，它首先对测试程序进行语法检查和编译，转换为信号模型对应的条目（信号类型、UUT 端口连接、信号范围、信号属性、方法调用等）；然后启动查询引擎，将虚拟资源定位到真实资源；接下来调用驱动引擎，按照连接模型执行UUT端口和信号端口连接算法，并执行信号模型规定操作，实现测试流程。
RTS机制保证了虚拟资源与真实资源完全隔离。虚拟资源只提出测试需求，不涉及ATS仪器配置。RTS在TPS运行中始终处于工作状态，捕获TPS的测试需求，控制驱动组件驱动实际仪器执行测试流程，直到TPS执行完成后才退出。
3.2 虚拟资源管理机制实现
资源管理层是平台的核心层。在RTS组件中的“虚拟资源管理器”模块的作用是对具体信号进行分析，然后对具体仪器进行选取和驱动。虚拟资源管理结构如图4所示。
3.2.1 虚拟资源建模
平台中虚拟资源采用TFF信号模型建模方法和组件技术，按照面向对象的思想，将信号分为有限的几类：常值、斜坡、随机、指数、脉冲、阶越、衰减正弦、梯形、噪声（非周期类），正弦曲线、三角、方波、标准正弦、其他波形（周期类）。其中，每类信号都以统一参数属性表建模，以便于实例化。
3.2.2 信号驱动组件
仪器驱动组件模型采用TFF 信号驱动组件模型，模型包括信号信息（名称和逻辑地址等）、信号属性、信号能力、信号端口及其信号驱动方法。这和虚拟资源的需求是一一对应的，有利于虚拟资源到真实资源的映射。同时它还包含信号名称、逻辑地址及其能力等信息，提供给RTS做查找真实资源和定位。具体来说，向上对信号驱动组件通过信号模型中的方法和事件实现，向下对底层仪器的操作使用通用的重封装的具体仪器驱动实现。
3.2.3 资源模型实现
测试资源模型提供ATS对系统资源配置和与被测单元连接通路的数据模型及管理，资源模型包括设备模型、配置模型及适配器模型，使用数据库建立和表示模型，使模型规范化和易修改。
设备资源模型DM描述了具体资源的相关信息，是实现资源管理器依照信号需求选择仪器的基础。在数据库中通过设备记录表和设备功能表来描述设备模型：设备记录表描述了ATE系统中所有的测试设备的相关信息；设备功能表记录了测试系统中仪器设备的信号发生/测试能力。
配置CM模型定义了具体测试系统的开关资源的输入、输出关系。其中包含了各种开关资源、模拟总线的连接问题，因而具有较复杂的连接关系。适配器模型AM定义了开关资源与UUT的连接关系，与配置模型比较类似。采用数据库表的形式来建模，与测试系统配合，实现仪器的匹配、通道的选择和整条通路的连接。
图4 虚拟资源管理结构
3.3 最佳通路选择问题
实际应用中，具体的硬件设备种类比较多，而且每一种硬件设备都能实现多种信号功能，开关和通路连接也不止一种方式，这样就带来RTS对仪器和通路的选择问题。
测试路径搜索可以用到状态图搜索的理论，目前成熟的算法也比较多。根据实际问题的情况和对最优解的需求，选取A*算法作为最优测试路径选择问题的基本解决方法。A*算法通过对估价值的计算来处理节点的取舍，在最优测试路径选择的实际问题中，在计算估价值之前利用约束条件、节点位置等信息减少节点的数量，极大地减少搜索的盲目性，迅速求得最佳路径。
结语
在已有平台上的试验证明，这种软件平台的设计是可行的。基于国际标准设计测试系统软件平台，解决了仪器互换性和TP可移植问题，体现了面向对象的思想，实现了测试系统软件平台的通用性。
技术专区
- 慕尼黑电子展艾德克斯：结合配套软硬优势，提供最佳测试方案
- 益莱储与您相约EDICON 2018，助力客户踏上新征程
- 功率计数据测试不稳定该怎么办？
- 泰克解读物联网如何推动电源效率、测试策略的创新
- 基于TLC549数字电压表的设计
