针对多种UUT的通用ATS软件设计开发过程中，UUT和测试资源的种类和数量将激增，同时TPS也将有多个。为此，要对图1所示ATS软件概念模型进行扩展，由二维模形转变成三维模形，如图2所示。图1和图2的内涵是一样的，只不过在三维概念模型中，存在多个UUT和多个测试资源通过多个TPS实现的多对多映射关系，失去了两维模型中一对一映射关系的单纯性，而这也是当前ATS软件开发过程中具体工程应用现状的客观体现。

    ATS软件概念模型需要实现两部分内容，分别是测试信息的描述和测试程序" title="测试程序">测试程序的实现。为此，本文把这两个方面分别用信息模型和系统模型来描述。
2 软件ATS信息模型
    在ATS软件概念模型中，信息是核心要素，如何来描述和交换信息是ATS软件实现的关键。ATS软件信息模型是在概念模型的基础上，主要对其信息要素进行建模，从信息描述和交换的角度深刻挖掘ATS软件的本质。
    本文把数据库理论中的实体-关系图模型进行了扩展，界定实体-关系图中的实体不仅仅是物理实体，也可以包括行为实体和数据实体，而把它们统一称为信息实体。基于此，采用实体-关系图模型构建的ATS软件信息模型如图3所示。

    在ATS信息模型中，主要有三个重要的信息实体：测试、诊断和维修。位于某一测试上下文中的UUT由测试行为来标记其正常测试规格，而异常行为标记其故障特征，UUT通过测试端口与测试资源通讯，建立物理连接关系；测试实体通过测试资源实现与UUT的物理连接，并运行自身的TPS控制仪器资源来实现观测UUT某一端口上的测试行为的目的，这一过程得到的测试数据作为故障诊断推理和标记UUT异常行为的基础；诊断实体建立在依据UUT模型得到的诊断知识之上，它首先根据诊断任务选择测试活动并对其进行排序从而生成测试执行序列，其次诊断实体参考测试数据标记UUT的某一异常行为出现与否，而后通过诊断模型对异常行为的具体位置、故障现状等情况进行判定，最后通过一系列维修活动纠正UUT的异常行为，从而实现服务于UUT维修保障的最终目的。
    为了清楚地描述测试信息，本文提取和定义了ATS软件信息模型中的信息实体，信息实体包括被测对象UUT、UUT测试、测试仪器" title="测试仪器">测试仪器、测试平台" title="测试平台">测试平台、测试适配器、测试配置、测试数据、故障诊断和故障维修等九个，各自的描述范畴和内容如下所示：被测对象UUT提供了描述某一特定UUT的能力，包括UUT的标识、接口以及物理、电气、操作特性等信息，它用来辅助UUT测试描述信息实体生成可执行的TPS，并保证该TPS在不同ATS之间移植；UUT测试描述UUT基本信息、测试性能、测试条件、电源需求、测试序列、诊断需求、相关支持设备的连接和操作以及测试程序的自动生成等信息，这些信息是开发可执行TPS的基础；测试配置描述在具体的测试平台上测试某一个UUT所必须的硬件、软件与文档信息，这些信息指向了其他信息实体；测试适配器描述UUT与测试平台之间的连接关系，包括应用环境需求、连接接口、物理/电气特性等信息，这些信息用于描述适配器的适用环境，定位UUT和ATE（Automated Test Equipment）之间的信号路径，便于实现TPS的移植性；测试平台描述平台上测试资源的接口、物理/电气特性、通道、校准以及自检等信息，其为ATS自检和校准以及TPS执行时的通道转换和信号路由提供服务；测试仪器主要是对传统仪器、综合/虚拟/组合仪器进行静态描述，该描述信息为TPS运行时标定仪器和进行资源分配提供服务，描述内容包括仪器生产商、序列号、功能、端口、指标等信息；测试结果描述在某一ATE上执行TPS进行某一UUT测试时的测试数据定义信息，包括UUT描述、测试平台描述、测试程序TPS、测试值、对测试结果通过与否的判定、操作人员、先前的维修活动以及操作环境等，测试数据信息用于分析、处理、显示和共享以及后期的故障诊断操作；诊断描述执行和分析UUT某一故障所必需的诊断推理信息和过程定义，这些信息用于闭环故障诊断及其相关操作；维修信息描述在故障诊断结果的基础上所要进行的维修活动。
    ATS信息模型通过标记测试环境中的物理实体（如被测对象UUT、测试仪器等）、行为实体（如测试行为、诊断行为、维修行为等）和数据实体（如测试数据、诊断知识等）来完整地展现ATS信息实体之间的关系，描述了ATS内部的UUT测试需求信息和测试资源功能信息的流动过程，为ATS系统模型的实现提供了信息支持。
    有关基于XML语言的信息实体描述方法参见文献[2]，不再赘述。
3 ATS软件系统模型
    ATS软件系统模型从开发人员的角度对ATS软件的TPS设计进行建模，旨在依靠计算机软件实现自动化的ATS信息交互过程。
为了清楚地描述ATS软件的层次结构，本文把ATS软件系统模型建立在ABBET层状模型^[3]基础之上，如图4所示。

    ATS系统模型共分成六个层次：产品描述层、测试需求/策略层、测试程序层、资源管理层、仪器控制层和硬件层。采用层状结构的最大好处是可以体现ATS软件的整体结构和接口连接关系。ATS软件系统模型的层次划分与ABBET标准定义的ATS层状模型的主要区别是增加了硬件层，旨在便于把系统模型中需要的测试信息和接口信息与ATS硬件的对应关系体现出来。
    在ATS软件系统模型的接口连接关系上，各层之间分别通过产品描述文档、测试/诊断需求描述文档、虚拟资源、仪器驱动器和硬件总线接口实现连接。
3.1 产品描述层和测试需求/策略层
    从UUT测试和故障诊断的角度出发，产品描述层和测试需求/策略层是一致的，目的均是描述UUT的测试/诊断需求，二者的不同之处在于产品描述层在UUT设计阶段定义UUT的测试行为，进而形成测试需求文档传递到UUT的测试维修过程中去，而测试需求/策略层是在UUT的维护阶段提取UUT的测试/诊断需求并给出测试/维修策略，进而形成测试需求文档，因此产品描述文档可以是UUT测试需求文档的一部分或者就是UUT测试需求文档本身。
    产品描述层和测试需求/策略层的实现对应于ATS信息模型的UUT和UUT测试需求两个信息实体，采用XML语言进行描述，详细实现过程参见文献[2]。
3.2 测试程序层
    在测试程序层中，TPS把UUT测试/诊断需求转化为计算机可编译执行的软件代码，因此从深层次来讲，TPS是对UUT测试/诊断需求的另一种表达方式，而这种方式可被COTS编译器所理解和编译运行，进而实现测试任务，得到测试数据，实现UUT的故障诊断和维修。
    测试程序的具体实现方法是多种多样的，如基于ATLAS语言的实现方式、基于XSLT转换语言的XML实现方法[5]和基于COTS语言的实现方法等。在这几种实现方法中，ATLAS语言已经过时且编译器（如PAWS等）价格昂贵；基于XSLT转换语言的XML方式缺乏规范的实现步骤且具体工程操作过程中工作量巨大，设计复用性差；而以COTS语言为工具，基于组件的ATS软件设计实现方法是作者的最终选择，详细实现过程参见文献[2]。
3.3资源管理层
    资源管理层是ATS软件系统的重要组成部分，它实现了承载UUT测试需求的TPS和测试资源功能之间的对接，在仪器驱动器的支持下，为ATS软件系统的仪器互换性、软件移植性和系统互操作性问题提供了解决方案。
    在资源管理层中分别用测试仪器模型、测试平台模型、测试适配器模型和测试配置模型规范了测试资源功能、测试平台通道连接关系、测试适配器信号变换和通道转接关系以及UUT测试配置等信息实体的描述内容，它们是测试资源管理的基础。在这四个模型中，前三个作为ATS中测试资源能力描述的组成部分，对ATS的测试功能进行描述，第四个提供UUT测试的系统配置信息。四个模型的实例化文档共同为RTS提供信息支持，分别由ATS信息模型给出的测试仪器Schema、测试平台Schema、测试适配器Schema和测试配置Schema进行定义，信息描述方法同样采用XML格式。
    在测试资源管理信息的配合下，RTS将把TPS中标记的虚拟资源需求映射到真实的物理资源控制上来，这种映射关系是通过虚拟资源描述和物理资源能力描述中的信号索引来完成的^[1]。关于面向信号的测试资源能力映射方法参见文献[2]。
    测试资源的能力是通过面向信号的仪器驱动器表现出来的，资源和通道映射成功后RTS将调用测试仪器和开关系统的驱动程序完成对物理仪器的功能调用。
3.4 仪器控制层
    仪器控制层完成测试仪器和开关通道的控制，面向信号的仪器驱动器设计在封装内部实现时可以调用的具体仪器驱动器类型有VPP、IVI、IVI-MSS等，而具体的物理控制指令可以是VISA、SCPI、488.2中的一种或几种混合起来。
    VISA规范屏蔽了测试仪器的物理接口，仪器接口可以是VXI、PXI、GPIB、PCI、LXI等类型中的任意一种。对于不同接口的测试仪器的相似功能，VISA均通过相同的控制代码来实现。
4 模型之间的关系
    对于ATS而言，概念模型是ATS软件模型的精髓所在，它是ATS软件的灵魂，是信息模型和系统模型的出发点和立足点。信息模型解决ATS软件概念模型的信息描述和交换问题，是ATS软件系统模型需要解决的具体任务，它捕获ATS软件系统的信息需求，把整个ATS分成九个信息实体，划分了各信息实体之间的接口关系和每个信息实体具体的描述范畴，这些信息实体作为TPS运行时系统的信息来源，方便了UUT测试需求信息和测试资源能力信息在ATS系统模型内传递，约束了系统模型的行为。系统模型在RTS的支持下具体实现ATS的信息交互过程，它从ATS信息模型中获取相关测试信息，是ATS信息交互过程的具体实现，ATS系统模型把测试软件分成五个层次，各层次之间均由标准化接口来实现信息的传递和过程的调用。
    ATS信息模型主要从用户的角度对UUT的测试需求和实现过程建模，它描述ATS软件的信息实体及其相互之间的关系，是不可执行的，信息交互过程需要依靠系统模型来实现；而系统模型从设计实现TPS的角度对ATS软件进行建模，它把UUT的测试需求信息和ATS测试资源能力信息转化成ATS软件实体，是可执行的，而具体的信息需求要靠信息模型来提供。因此，从ATS软件实现的角度来讲，信息模型和系统模型之间的关系是对立统一的，整个ATS软件开发过程需要把二者集成在一起。
    本文建立了ATS软件的概念模型、信息模型和系统模型，阐述了三种模型之间的关系，解决了当前由于ATS的规模和复杂度急剧增加带来的ATS软件系统集成和描述问题，对具体的ATS软件工程设计和实现过程具有广泛的指导作用。
参考文献
[1] IEEE Std 1641-2004. IEEE Standard for Signal and Test Definition. 2004.
[2]  刘金宁. 自动测试系统软件模型与关键实现技术研究[D].军械工程学院博士学位论文， 2007.
[3]  IEEE Std 1226-1998. IEEE Trial Use Standard for A Broad Based Environment for Test（ABBET）Overview and Architecture[J]. 1998.
[4]  SHEPPARD J W, SIMPSON W R. A systems view of test  standardization[C]. In AUTOTESTCON, 1996.
[5]  O’DONNELL S J, RICHARDSON P. Implementing ATML into an existing software architecture[C]. IEEE Proceedings of AUTOTESTCON 2004：209-216.