CN101073016B - 用于执行测试器工具模块的安装和配置管理的方法和系统 - Google Patents

Abstract

本发明揭示一种用于管理模块化测试系统中的多个硬件测试模块版本、软件组件和测试器操作系统(TOS)版本的方法。所述方法包含在档案中安装与所述模块化测试系统兼容的所述TOS版本，和在所述档案中安装对应于所述硬件测试模块版本的卖方软件组件。所述方法进一步包含：创建用于描述对应于所述硬件测试模块版本和所述TOS版本发明的卖方软件组件的系统简档；为所述模块化测试系统选择系统简档，其中所述系统简档包含一组兼容的卖方软件组件和用于测试特定硬件测试模块版本的选定TOS；和激活所述模块化测试系统上的所述选定TOS。

Description

用于执行测试器工具模块的安装和配置管理的方法和系统

相关申请案的交叉参考

本申请案主张2004年12月9日申请的第60/635,094号美国临时申请案“Method andSystem for Performing Installation and Configuration Management of Tester InstrumentModules”的优先权，该申请案让渡给本申请案的受让人，且其全文以引用的方式并入本文中。

技术领域

本发明涉及测试集成电路的领域。确切地说，本发明涉及一种用于执行测试器工具模块的安装和配置管理的方法和系统。

背景技术

测试设备之所以具有较高成本，一个主要原因在于常规测试器架构的专用性质。每个测试器制造商具有许多测试器平台，其不但在例如Advantest、Teradyne和Agilent等公司之间互不兼容，而且在公司内部的平台(例如Advantest制造的T3300、T5500和T6600系列测试器)之间也不兼容。由于这些不兼容性，每个测试器均需要其自身的专用硬件和软件组件，且这些专用硬件和软件组件无法在其它测试器上使用。此外，将测试程序从一个测试器转移到另一个测试器上以及开发第三方解决方案，需要付出大量精力。即使针对一个平台开发出第三方解决方案，也无法将这个第三方解决方案转移到不同平台上或在不同平台上重新使用。从一个平台到另一平台的转译过程一般较为复杂且容易发生错误，从而导致付出额外的精力、时间且测试成本增加。

专用测试器架构的另一问题在于，所有硬件和软件对于给定测试器来说始终保持固定的配置。为了测试被测装置(device-under-test，DUT)或IC，开发出一种专用测试程序，其使用测试器能力中的一些或所有能力来定义测试数据、信号、波形和电流及电压电平，并且收集DUT响应且判断DUT是通过还是未通过测试。

开放式架构测试系统为传统测试系统的上述问题提供了解决方案。第10/772,434号美国申请案“Method and Structure to Develop a Test Program for Semiconductor IntegratedCircuits”中描述了开放式架构测试系统的一实例，该申请案的全文以引用的方式并入本文中。所述开放式架构测试系统可经配置以支持多种卖方硬件测试模块及其相应的DUT。

发明内容

然而，实施此种开放式架构测试系统的一个难题是，可能存在多个版本的测试器操作系统(TOS)。此外，每个卖方硬件测试模块可能具有多个版本，且卖方硬件测试模块的每个版本可能具有其相应的软件组件的版本。测试器操作系统、卖方硬件测试模块和软件组件的版本需要无缝协作，以便在卖方硬件测试模块上运行测试。因此，需要这样一种模块化测试系统，其能够管理多个卖方硬件测试模块版本、软件组件版本和TOS版本，以便使用多种卖方硬件测试模块来测试DUT。

在一个实施例中，一种用于管理模块化测试系统中的多个硬件测试模块版本、软件组件和测试器操作系统(TOS)版本的方法包含：将与所述模块化测试系统兼容的TOS版本安装在档案中，和将对应于所述硬件测试模块版本的卖方软件组件安装在所述档案中。所述方法进一步包含：创建用于描述对应于所述硬件测试模块版本和所述TOS版本的卖方软件组件的系统简档；为所述模块化测试系统选择系统简档，其中所述系统简档包含一组兼容的卖方软件组件和用于测试特定硬件测试模块版本的选定TOS；和激活所述模块化测试系统上的所述选定TOS。

在另一实施例中，一种用于管理多个硬件测试模块版本、软件组件和测试器操作系统(TOS)版本的系统包含：系统控制器，其用于控制至少一个现场控制器；至少一个现场控制器，其用于控制至少一个硬件测试模块；与模块化测试系统兼容的测试操作系统版本；对应于硬件测试模块版本的卖方软件组件；和用于描述对应于硬件测试模块版本和TOS版本的卖方软件组件的系统简档。

附图说明

结合以下附图阅读对本发明实施例的详细描述之后，将可更清楚地理解本发明的上述特征和优点以及本发明的其它特征和优点。

图1a说明根据本发明实施例的开放式架构测试系统。

图1b说明根据本发明实施例的用于管理模块化测试系统中的多个硬件测试模块版本、软件组件和TOS版本的方法。

图2a说明根据本发明实施例的TOS控制和工厂默认目录结构。

图2b说明根据本发明实施例的开放式架构测试系统的状态图。

图3说明根据本发明实施例的TOS安装目录结构。

图4说明根据本发明实施例的用户SDK安装目录结构。

图5说明根据本发明实施例的卖方SDK安装目录结构。

图6说明根据本发明实施例的TOS部署目录结构。

图7说明根据本发明实施例的用户SDK部署目录结构。

图8说明根据本发明实施例的卖方SDK部署目录结构。

具体实施方式

本发明提供用于执行测试器工具模块的安装和配置管理的方法和系统。提出以下描述以使所属领域的技术人员能够制造和使用本发明。对具体实施例和应用的描述仅作为实例而提供。所属领域的技术人员将容易了解本文描述的实例的各种修改和组合，且在不偏离本发明的精神和范围的情况下可将本文定义的一般原理应用于其它实例和应用。因此，并不希望将本发明局限于所描述和展示的实例，而是应符合与本文揭示的原理和特征一致的最广泛范围。

图1a说明根据本发明实施例的开放式架构系统。如图1a所示，系统控制器(SysC)102耦合到多个现场控制器(SiteC)104。系统控制器也可耦合到网络以存取文件。通过模块连接启用器106，耦合每个现场控制器以控制位于测试现场110的一个或一个以上测试模块108。模块连接启用器106允许重新配置连接的硬件模块108，且还用作用于数据传送(用于加载图案数据、收集响应数据、提供控制等)的总线。可能的硬件实施方案包含专用连接、切换连接、总线连接、环形连接和星形连接。模块连接启用器106可通过(例如)切换矩阵来构建。每一测试现场110与被测装置(DUT)112相关联，所述被测装置通过加载板114连接到相应现场的模块。在一个实施例中，可将单个现场控制器连接到多个DUT现场。

系统控制器102用作整体系统管理器。其协调现场控制器活动、管理系统级并行测试策略，且还提供处置器/探测器控制以及系统级数据记录和错误处置支持。根据操作性设置，可将系统控制器102部署在与现场控制器104的操作分离的CPU上。或者，系统控制器102和现场控制器104可共享共同的CPU。类似地，可将每一现场控制器104部署在其自身的专用CPU(中央处理单元)上，或作为同一CPU内的单独的程序或线程。

可概念上将系统架构看作图1a所示的分布式系统，且应了解，也可将各个系统组件视为集成的单片系统的逻辑组件，而不是必然地将其视为分布式系统的物理组件。

图1b说明用于管理模块化测试系统中的多个硬件测试模块版本、软件组件和TOS版本的方法。TOS的多个版本及其相关联的用户和卖方SDK版本以及卖方驱动器软件的多个版本存储在档案中。开放式架构测试系统“安装和配置管理(ICM)”系统的意图是允许卖方开发驱动器软件组件以支持其硬件模块，且允许用户选择用于在测试器或开发平台上操作的兼容的卖方驱动器软件和TOS版本。ICM系统还对在测试器或开发平台上安装这些选定的配置并视情况而激活选定的配置进行管理。

ICM系统描述管理开放式架构测试系统的TOS的要求和所涉及的活动。用于开放式架构测试系统的ICM涉及四个主要活动：

1.安装

这是指将开放式架构测试系统组件拷贝到档案以供稍后激活或部署的动作。

2.配置

这是指允许用户与ICM系统互动以创建、保存软件配置并修改软件配置作为用于激活的系统简档的动作。

3.激活

这是指使选定的软件配置(即，简档)成为特定测试器上的有效软件配置(即，对其进行部署)的动作。

4.审核

这是指提供特定测试系统上当前有效的软件和硬件组件的列表的动作。

本文献为这些活动中的每一活动提供规范。在以下论述中，使用众所周知的缩写SW和HW来分别指代软件和硬件。

请注意，虽然安装和配置是特定针对ICM的活动(其概念上可在特定测试器的远端执行)，但激活和审核是特定针对测试器的，且需要来自特定开放式架构测试系统的TOS组件(主要是开放式架构测试系统的测试控制后台程序(TCD))的协作。因此，本文献还描述了ICM活动中涉及的TCD和TOS的方面，以及TCD本身的安装。为此目的，测试器控制和TOS启动部分首先提供对开放式架构测试器控制和TOS系统启动程序的描述。

还请注意，在更为复杂的软件发布版本之间，发布开放式架构测试系统软件“修补程序”是修改和增强开放式架构测试系统软件组件的核心部分。为此目的，软件修补程序发布版本部分提供对创建、分配和使用开放式架构测试系统软件修补程序发布版本所遵照的方法的描述。

(测试器控制和TOS启动)

在此部分中，我们描述开放式架构测试器控制和启动程序。假设读者熟悉特别是如将TOS组织成包括开放式架构测试系统的系统控制器(SysC)和现场控制器(SiteC)的一般分布式系统的过程中所呈现的开放式架构测试器架构的基本原理。

(测试器控制后台程序)

通过开放式架构测试系统的测试控制后台程序(TCD)来执行对开放式架构测试系统的TOS的一般控制。对于TCD的规范概括如下：

开放式架构测试系统的测试器控制后台程序负责以下功能：

在系统引导(boot-up)时或者根据用户命令而启动和初始化开放式架构测试系统的TOS，并在成功的系统初始化之后选择性地启动用户定义的开放式架构测试系统应用程序。

根据用户命令关闭开放式架构测试系统的TOS，其中包含关闭任何连接到TOS核心服务的开放式架构测试系统应用程序。

激活或部署开放式架构测试系统的特定软件配置(由系统简档定义)，其中“版本切换”本质上是激活当前实行的简档之外的简档。

以下描述用于开放式架构测试系统软件配置的系统简档，其是定义特定开放式架构测试系统软件配置所必需的信息的总体集合。对于论述内容的其余部分，测试器控制后台程序是指Windows操作系统(OS)中使用的测试器控制后台程序；然而，所述概念是普遍性的，且可应用于任何开放式架构测试系统。

Windows系统中的TCD是Win32服务(其出现在使用Windows控制面板可看到的服务对话框中的已安装服务的列表中)，所述Win32服务在SysC和所有SiteC上安装并自动运行。COM组件提供介接方法(在系统控制器侧)以执行以上功能。其与开放式架构测试系统软件(联机版本是由系统集成器在工厂安装的)分开安装，且向Windows服务控制管理器注册以在OS引导时间自动启动。请注意，虽然主TCD是在系统控制器上运行的TCD，但辅助TCD在现场控制器上运行，并且负责在主TCD的支持下工作以带动各个现场控制器。

(TOS控制和工厂默认目录)

为了正确地安装后台程序并使其正确地运行，每一开放式架构测试系统预先配置有标准目录结构，用于包含TOS控制组件和工厂默认信息。将此概括为以下规范：

每一开放式架构测试系统的系统控制器和现场控制器经配置以具有TOS控制和工厂默认目录结构，其根目录位于可看到的<MAINTENANCE_ROOT>位置，且具有图2a中展示且表1中描述的结构。

表1描述图2a所示的结构。请注意，第一列中列出的目录是相对于<MAINTENANCE_ROOT>的。

目录	说明
		./bin./cfg./doc./logs	含有TCD控制器应用程序和相关联的动态链接库(DLL)。含有规定测试器的工厂默认设置的配置文件。含有TCD和工厂默认相关文档；可根据文档类别分成子目录。TCD安装程序记录其操作的位置。

表1.TOS控制和工厂默认目录内容

安装在<MAINTENANCE_ROOT>/bin中的TCD控制器应用程序旨在成为简单的命令线应用程序，且可向TCD发送基本的测试器系统控制命令，例如“启动”、“停止”、“激活”等。Advantest T2000系统用应用程序t2kctrl来执行这些任务。

<MAINTENANCE_ROOT>/cfg目录的内容视系统集成器的不同而可能不同；在每种情况下，其均含有相应TCD或其安装程序运行所需的测试器信息。举例来说，AdvantestT2000测试器系统将以下信息放置在<SystemDrive>:/T2000Maintenance/cfg中。请注意，<SystemDrive>是Windows预定义的环境变量；在Windows 2000上默认其为“C:”。

现场控制器的工厂配置(用标准Windows INI文件格式)规定工厂处提供的所有现场控制器的内部系统IP名称和地址，连同开放式架构测试系统软件激活程序执行其任务所必需的任何特殊的开放式架构测试系统用户账号和密码信息。文件命名为OASISSiteInfo.ini。

用户可能不会在联机系统上修改此文件。对于脱机系统来说，用户可在需要时依据默认(其指定同一机器上的单个SiteC作为SysC)来修改此文件。对于既以联机方式又以脱机方式使用的系统来说，联机模式需要使用原始联机工厂配置文件(或者最近被厂方授权技术人员更新以反映硬件布局变化的配置文件)。

工厂默认规范(FDEF)文件，其含有关于以下内容的信息：

总体测试器属性(例如类型、名称、操作频率等)；

在工厂配置的硬件模块及其板特定细节；

在工厂配置的与硬件模块连接的开放式架构测试系统模块连接启用器(MCE)端口；

开放式架构测试系统与每一硬件模块的同步矩阵连接(如果存在的话)；和

用于硬件模块的测试头连接。

用户可能不会在联机系统上修改此文件——只可由改变机器物理配置的授权维修人员来进行修改。对于脱机系统来说，工厂默认规范文件定义与所提供的测试实例(如果存在的话)兼容的虚拟机器配置；用户可能会在需要时对其进行修改，以便配置其自身的虚拟测试器。对于既以联机方式又以脱机方式使用的系统来说，联机模式需要使用原始联机工厂配置文件(或者最近被厂方授权技术人员更新以反映硬件布局变化的配置文件)。

(测试器状态和状态过渡)

如上所述，TCD负责启动开放式架构测试系统的TOS。为了理解TOS带动的机制，必须首先理解TOS可处于的状态，以及其间所允许的过渡。图2b中展示开放式架构测试器的状态过渡图。

图2b中的状态的含义如下：

状态0：测试器系统闲置：系统控制器上的TCD不在运行，且TOS不在运行。

状态1：TCD至少在系统控制器上运行；然而，TOS尚未运行。

状态2：开放式架构测试系统的系统控制器程序正在运行，但尚未初始化；TCD可能或可能不在所有现场控制器上运行；在脱机模式中，开放式架构测试系统的测试器仿真器程序尚未运行。

状态3′：(仅脱机模式)开放式架构测试系统的测试器仿真器正在(单个指定的)现场控制器计算机上运行。

状态3：至少已成功初始化现场控制器1(SITEC-1)，且系统处于默认划分状态(即，所有硬件模块均通过MCE连接到SITEC-1)；此外，所有指定的现场控制器也可能已经成功初始化。此时，系统“准备就绪”，即，经配置以接受测试计划加载请求。

状态4：已将用户测试计划成功加载到一个或一个以上兼容的现场控制器上，所述系统可能已经被(重新)划分成现场控制器的一部分以便适应测试计划要求。

以下描述导致图2b所示的状态过渡的事件，其中符号“t(x，y)”指示从状态x到状态y的过渡(请注意，在以下论述中客户端是系统控制器TCD的客户端，且可为任何连接并使用TCD上的适当接口的远程或本机应用程序)：

t(0，0)接收到来自Windows引导程序的命令(或者交互的手动“启动”请求)时，Windows服务控制管理器未能在Windows引导期间启动系统控制器上的TCD。

t(0，1)接收到来自Windows引导程序的命令(或者交互的手动“启动”请求)时，Windows服务控制管理器成功地启动系统控制器上且可能是现场控制器上的TCD。

t(1，1)接收到“启动”TOS的客户端命令时，系统控制器上的TCD未能启动TOS系统控制器程序。

t(1，2)接收到“启动”TOS的客户端命令时，系统控制器上的TCD成功地启动TOS系统控制器程序。

t(2，2)作为“启动”TOS的客户端命令的一部分，TOS系统控制器程序的初始化失败，即，其未能在脱机模式下启动开放式架构测试系统的测试器仿真器程序，或者未能启动和初始化至少SITEC-1上的TOS现场控制器程序。

t(2，3′)(仅脱机模式)作为“后动”TOS的客户端命令的一部分，TOS系统控制器程序成功地启动(单个指定的)现场控制器计算机上的开放式架构测试系统的仿真器程序。

t(3’，3)^*(仅脱机模式)作为“后动”TOS的客户端命令的一部分，TOS系统控制器程序成功地启动和初始化至少SITEC-1的TOS现场控制器程序(且可能启动和初始化所有指定的现场控制器的程序)。

t(3′，2)(仅脱机模式)作为“后动”TOS的客户端命令的一部分，TOS系统控制器程序未能启动和初始化至少SITEC-1的TOS现场控制器程序(终止仿真器程序)。

t(2，3)^*(仅联机模式)作为“启动”TOS的客户端命令的一部分，TOS系统控制器程序成功地启动和初始化至少SITEC-1上的TOS现场控制器程序(且可能启动和初始化所有指定的现场控制器上的程序)。

t(3，3)当接收到加载用户测试计划的用户命令时，TOS未能加载指定的测试计划。

t(3，4)当接收到加载测试计划的用户命令时，TOS在按照与指定的测试计划相关联的套接字的要求成功地(重新)划分系统(如果必要的话)之后，成功地在指定的现场控制器上加载测试计划。

t(4，4)当接收到(重新)加载(相同或不同的)测试计划的用户命令时，TOS在按照与指定的测试计划相关联的套接字的要求成功地(重新)划分系统(如果必要的话)之后，成功地在指定的现场控制器上(重新)加载测试计划。

t(3，1)当接收到“关闭”TOS的客户端命令时，TCD停止TOS。

t(4，1)当接收到“关闭”TOS的客户端命令时，TCD在停止运行中的测试计划(如果存在的话)之后停止TOS。

请注意，^*是指过渡伴随着TOS系统控制器程序试图启动用户指定的应用程序；未能启动这些应用程序中的任何或所有应用程序并不代表未能成功进行TOS初始化，因为应用程序不是TOS的一部分。

除了以上展示的过渡之外，在系统控制器上执行的Windows“关闭”命令(或系统的物理断电)会将测试器重设为状态0，不论其当时处于何种状态。

(TOS启动程序)

带动开放式架构测试系统的TOS的程序如下(假设已正确定义环境变量OASIS_INSTALLATION_ROOT、OASIS_ACTIVE_CONFIGS、OASIS_TOS_SETUP_FILE、OASIS_TPL_SETUP_FILE、OASIS_TOOLS_SETUP_FILE、OASIS_MACHINE_DIR和OASIS_TEMP，且已选择系统简档)：

1.系统通电(或引导)时，Windows服务控制管理器启动系统和现场控制器上的TCD。

2.系统控制器上的TCD核实系统简档有效、读取由简档指定的现场控制器的配置——即，文件$OASIS_ACTIVE_CONFIGS/OASISSys.cfg——并启动TOS系统控制器程序。

3.TCD接着对TOS系统控制器程序调用初始化()方法，其导致

a.在且仅在操作模式是脱机的情况下，在(单个指定的)现场控制器计算机上启动测试器仿真器程序；

b.请求每一现场控制器上的TCD以启动其TOS现场控制器程序；

c.对每一TOS现场控制器程序调用初始化()方法；和

d.在已成功地初始化至少SITEC-1之后，对系统进行默认划分(其中将所有硬件模块通过MCE连接到SITEC-1)。

4.TCD接着试图以指定的次序启动当前有效简档中针对自动启动而列出的任何用户应用程序。

步骤0 0中任何步骤期间的失败均会导致上述相应的系统状态过渡。步骤0或0处的失败被记录在Windows事件日志中。步骤0处的失败被TOS系统控制器程序记录，并且可供与其连接的任何客户端应用程序随后进行检索。

可选的自动应用程序启动

如上所述，开放式架构测试系统使得用户可添加在成功的TOS启动后应自动启动的应用程序。OCTool允许用户指定其对此类应用程序的选择作为系统简档的一部分。当在特定测试器上激活了此种简档(即，使得所述简档指定的配置成为当前有效的)时，在成功的TOS初始化完成时执行步骤0。

为为此，TCD读取文件OASISVer.cfg的启动部分，所述文件OASISVer.cfg是指定选定的系统简档的属性的数据文件，且采用标准windows INI文件格式。其将所述部分中的每一线视为开始新应用程序的命令线。未能开始所列出的应用程序中的任何或所有应用程序在TOS带动方面并不意味着错误状态，因为应用程序并不是TOS的一部分。然而，会记录下任何此类失败并将其存储(为了供应用程序以后检索)在TOS系统控制器程序中。

安装

开放式架构测试系统的安装包括安装三个主要组件，其中每一组件均独立安装：

1.开放式架构测试系统的测试器控制后台程序(TCD，其概述开放式架构测试系统软件激活或部署的功能性)。

2.开放式架构测试系统的配置工具(OCTool)。

3.开放式架构测试系统的系统软件。

在此部分中，针对这些组件中的每一者描述安装过程。

(TCD安装)

独立于任何其它开放式架构测试系统组件来安装开放式架构测试系统的TCD程序包。对于刚出厂的联机系统，通常可预先安装TCD程序包。对于脱机系统且对于对TCD的更新总体来说，可通过系统集成器来提供安装程序。

在Windows中，开放式架构测试系统<MAINTENANCE_ROOT>自然转译成通常的Windows<SystemDrive>(常为“C:”驱动器)上的目录，因为确保存在<SystemDrive>。举例来说，开放式架构测试系统的Advantest T2000实施方案将根目录放置在系统和现场控制器上的目录“C:/T2000Maintenance”处。在以下论述中，假设<SystemDrive>为“C:”。在TCD程序包的初始化期间遵循的步骤如下：

1.如上所述，在SysC和SiteC上存在<MAINTENANCE_ROOT>，因为在<MAINTENANCE_ROOT>中安装有某些组件。

a.如果不存在<MAINTENANCE_ROOT>，那么TCD安装程序会创建<MAINTENANCE_ROOT>。

b.如果不存在现场控制器工厂配置文件(Advantest T2000系统中的C:/T2000Maintenance/cfg/OASISSiteInfo.ini)，那么安装程序也会基于来自执行安装的人员的输入而创建所述配置文件。

c.如果存在开放式架构测试系统工厂默认规范(FDEF)文件(Advantest T2000系统中的C:/T2000Maintenance/cfg/OASISHW.def)，那么

i.对于联机系统，其决不会被取代或修改；

ii.对于脱机系统，将预先打包的版本(命名为<FDEF-name>.<example>，旨在模仿与具备开放式架构测试系统的实例兼容的虚拟测试器)拷贝到<MAINTENANCE_ROOT>/cfg中，且提醒用户用这个版本来代替现存的FDEF文件(如果其希望用开放式架构测试系统实例工作的话)。

d.如果不存在FDEF文件，那么

i.对于联机系统，安装样本FDEF文件，且警告用户要对其进行更新以便与他所安装的硬件兼容；

ii.对于脱机系统，将此文件的预先打包版本安装为FDEF文件(具有开放式架构测试系统所要求的标准名称)

2.安装程序将TCD二进制安装在<SystemRoot>/system32中，并针对任何所需要的COM组件注册设定Windows注册条目。

3.安装程序针对TCD设定以下配置属性：

a.自动启动：其指定Windows系统引导是否促使SysC TCD自动启动开放式架构测试系统的TOS(是，则为“真”；否，则为“假”)。默认的是“真”；执行安装的人员可在需要时将其设定为“假”。

b.模式：其指定TOS是应在“联机”(如果适用的话)操作模式下启动，还是应在“脱机”操作模式下启动。默认的是“联机”；且执行安装的人员可在需要时将其设定为“脱机”。

c.配置：其指定TOS是应以组件的“调试”版本启动还是应以“发布”版本启动。默认的是“发布”；执行安装的人员可在需要时将其设定为“调试”。

4.安装程序在<MAINTENANCE_ROOT>/bin中安装TCD控制器应用程序(t2kctrl)及其相关联的DLL。

5.对于开放式架构测试系统所需要的以下操作系统环境变量中的每一者，安装程序(i)确定其是否已经过设定；和(ii)如果尚未设定，那么将其设定为用户指定的值：

a.OASIS_INSTALLATION_ROOT

b.OASIS_ACTIVE_CONFIGS

c.OASIS_MACHINE_DIR

d.OASIS_TEMP

6.安装程序向Windows系统“路径”环境变量添加<MAINTENANCE_ROOT>/bin和$OASIS_INSTALLATION_ROOT/bin(假设根据Windows惯例，系统“路径”环境变量中已经存在<SystemRoot/system32)。

请注意，如步骤0所示，其所相依的TCD和DLL安装在Windows<SystemRoot>/system32目录(其在Windows 2000上为<SystemDrive>/WINNT/system32—最通常为C:/WINNT/system32)中，因为所述位置确保Windows服务的正确操作。此外，<MAINTENANCE_ROOT>需要存在于系统和现场控制器上，以便系统正确运行。因此，如果想要重新格式化驻存有这些组件的本机磁盘，那么应当仔细备份并重新存储<MAINTENANCE_ROOT>(以及TCD及其在<SystemRoot/system32中的相关DLL)。开放式架构测试器上的任何系统简档的激活均依赖于已在测试器上安装且可用的TCD。由于TCD本质上独立于开放式架构测试系统软件，所以要求其与开放式架构测试系统软件的所有发布版本向后兼容。

(OCTool安装)

将开放式架构测试系统配置工具OCTool分布并安装在与开放式架构测试系统软件分离的程序包中。

OCTool的安装程序允许用户为OCTool选择安装位置。OCTool允许用户创建和保存开放式架构测试系统的独立于测试器的系统简档。因此，可在概念上将其安装在远离特定测试器的任何位置中，只要其可访问安装有开放式架构测试系统软件的档案位置。然而，需要小心不要将其安装在其根目录在$OASIS_INSTALLATION_ROOT(其为当前有效的系统的根目录)处的目录树内的位置中，因为其因而可能会因为激活对应于不同简档的系统而丢失。

与TCD相同，由于OCTool本质上独立于开放式架构测试系统软件，所以其需要向后与开放式架构测试系统软件的所有发布版本兼容。

(开放式架构测试系统软件安装)

开放式架构测试系统软件的安装是指实体上将开放式架构测试系统软件组件(最终是文件)拷贝到操作系统环境变量OASIS_ARCHIVE_ROOT所定义的位置中的动作。下文中将这一位置称为档案。所述档案含有由开放式架构测试系统的卖方和系统集成器为系统用户提供的文件。请注意，其与部署或运行时间位置截然不同。与部署位置形成对比，档案位置实际上可远离测试器系统，只要其可由TCD访问即可，所述TCD在上面部署有所述软件的测试器系统上运行。

安装过程对于TOS和卖方组件来说是相同的。每一安装的文件具有组件配置记录(CCR)，其指定组件的属性。因此，以下两个要求概括了安装过程的规范：

开放式架构测试系统软件安装将文件拷贝到所定义的档案位置中。这一位置由环境变量OASIS_ARCHIVE_ROOT指定。

安装到档案的每一文件均伴随有组件配置记录或CCR，所述组件配置记录或CCR含有所需的文件描述信息。

因此，TOS和卖方文件驻存在共同的根目录下。对于待经由系统简档来管理的这些文件来说，其遵照开放式架构测试系统文件命名要求。通过遵照这些要求，可将系统上的文件累积在单个档案目录中以便进行管理。这适用于TOS和卖方安装的文件两者。接下来论述这些要求。

文件命名要求

为了实现版本管理、切换和审核，待安装在开放式架构测试系统中的每一组件(即，每一文件)均使用以下文件命名格式，所述格式防止所述名称与来自相同或不同卖方的其它已安装组件的名称冲突：

TOS和卖方组件使用以下命名格式：

卖方ID_组件名称_[D_]版本识别符[.ext]。

对于格式的描述如下，其中方括号([])内的元素代表可选项目：

1.卖方ID：两个到三个字母的卖方识别代码。这一代码将组件区分为TOS或卖方专用组件，并且便于消除文件歧义。请注意，每一卖方的责任是管理其引入到系统中的文件。第一字符应为字母数字且不可为下划线字符。TOS运行时间组件使用“OAI”作为识别符。卖方ID部分之后是下划线字符′_′。

2.组件名称：由组件供应方选择的任意名称。组件名称部分之后是下划线字符′_′。

3.D：这是可选的，且可应用于可执行组件。对于此类组件，当且仅当组件代表调试动态链接库(DLL)或可执行文件(EXE)时，组件名称之后才是′D′。没有′D′暗示组件是非调试版本(即“发布”版本)。如果存在′D′，那么′D′部分之后是下划线字符′_′。

4.版本识别符：所有引入到系统中的文件均具有清晰的版本号是一项基本要求。为了在不同操作系统之间兼容，将版本号表示为文件名的一部分，作为版本识别符字段。这一字段具有以下格式：

主要.次要.修补

其中主要、次要和修补中的每一者均为非负的整数值，其分别代表组件的主要、次要和修补版本。

5.ext：扩展名是(可选的)OS专用识别辅助，例如.dll、.exe、.txt、.doc等。

请注意，在所有情况下，文件名称在所有支持的平台(Windows、Linux等)上均是合法的。一些实例如下：

AT_PinModule_10.01.008.dll

AT_PinModule_10.01.008_D.dll

AT_HCPowerSupplyModule_09.45.003.dll

OAI_utils_00.03.000.dll

(安装目录结构)

如图3、图4和图5中展示且以下进一步描述，目录结构的根目录在OASIS_ARCHIVE_ROOT处。在以下论述中，软件开发工具包通常由其简写“SDK”来表示。此外，符号“$foo”指代操作系统环境变量foo的值。安装过程符合以下规定：

如图3、图4和图5中展示且在表4中描述，所有开放式架构测试系统软件组件文件均安装在$OASIS_ARCHIVE_ROOT下的适当位置中。

安装(即，档案)位置可从希望在上面激活TOS的测试器系统访问。

在图3、图4和图5中，命名为OAI的目录含有开放式架构测试系统的TOS文件，而命名为<vendor>的目录含有卖方专用文件。每一卖方具有其自身的目录，其中<vendor>表示唯一的两个到三个字母的识别符(例如：Advantest卖方目录标记为AT)。请注意，在每一卖方专用的目录内，卖方负责确保其文件名是唯一的。还请注意，对文件名中清晰的版本识别符的要求允许将相同组件的不同版本存储在相同位置中。

表2进一步描述上图中概括的目录结构，其中第一列中的每一目录是相对于$OASIS_ARCHIVE_ROOT。

目录	说明
		./bin./CDB./cfg./doc./InstallCCR./logs./profiles./{User，Vendor}SDK/bin	含有子目录OAI、<vendor>和sys用于存储可执行文件(DLL和EXE)。Sys子目录含有TOS所需要的系统专用的或第三方DLL，例如msvcrt70.dll、mfc70.dll等。(如果用户希望的话)可能含有开放式架构测试系统组件数据库，所述组件数据库保存档案中存在的所有CCR之间的关系。含有系统TOS或卖方组件使用的配置文件或者系统和卖方工具，后者组织成工具专用(<tool>)子目录。共同子目录旨在由卖方用来放置需要在TOS和一个以上卖方的组件之间共享的配置信息。含有文档，所述文档根据文档类别分成目录。在文件安装时间保存原始CCR的位置。安装程序在将文件加载到档案中时记录其操作的位置。用于存储简档的位置。每一简档的内容存储在单独的、已命名的目录(由<profileX>表示)中。含有SDK可执行文件，例如工具、实用程序、辅助应用程序等。

目录	说明
		./{User，Vendor}SDK/doc./{User，Vendor}SDK/examples./{User，Vendor}SDK/inc./UserSDK/inc/STL./{User，Vendor}SDK/lib./UserSDK/templates./UserSDK/TestClasses	含有SDK文档，所述文档根据文档类别分成目录。基本目录含有index.html文件，其用作基本目录下所有基于HTML的文档的顶级索引，其根据主题而组织在<html-dirs>中。用于存储SDK实例的位置。用于存储内含文件的位置。用于存储C++标准模板库(STL)文件层级的位置。用于存储库文件的位置。用于存储用户SDK所需要的模板文件的位置。OAI/OTPL子目录用于存储开放式架构测试编程语言(OTPL)编译器occ使用来进行其操作的模板。用于存储开放式架构测试系统的测试分类的位置。

表2.开放式架构测试系统安装目录结构

安装日志

目录日志含有子目录安装程序。这一位置支持以下规范：

用于开放式架构测试系统软件的安装程序在众所周知的位置(即，$OASIS_ARCHIVE_ROOT/logs/Installer)处创建安装日志。

用于TOS安装日志文件的命名惯例是OAI_<version>.log。卖方安装程序使用命名惯例<vendor>_<version>.log。另外两个要求如下：

安装日志是清晰地展示每一文件拷贝到档案中的完全合格的路径的文本文件。

如果安装程序运行多次，从而增加或去除组件，那么更新安装日志以展示拷贝到档案中或从档案中去除的文件的当前状态。

新组件版本安装

当发布了组件的新版本时，组件供应方(TOS或卖方)为新组件版本提供CCR。组件组成部分的文件名反映了组件的新版本，如文件命名要求部分中所描述；遵照文件命名规则会防止覆写掉现有文件。因此，组件文件版本继续在档案目录中积累。

请注意，安装程序包(如下述发布群组CCR或直接卖方发布版本的任何卖方提供的发布版本CCR中的一者所指示)可能含有旨在修改或增强组件的当前发布的版本的个别组件。由于现有组件的新版本并不替换现有组件/文件，所以任何预先存在的系统简档可仍然运行。请注意以下对于组件的修补程序的要求：

当使得新的修补程序可用时(表现为主要.次要.修补三重版本识别符的修补组件的变化)，其与TOS发布版本的主要/次要版本兼容。

下文中在发布群组CCR之后提供此种“修补程序”的详细机制，且已描述用户的系统简档。

配置

配置是指允许用户与ICM系统互动以将开放式架构测试系统软件配置创建、保存和修改为系统简档的动作，所述系统简档稍后用来激活特定测试器系统上的特定配置。此部分描述由ICM提供来执行此功能的机制。

(组件和配置记录)

在开放式架构测试系统中，组件是一个或一个以上文件、环境设置等，其代表系统中的截然不同的模块。系统组件的一个重要类别是系统硬件模块的软件表示形式，将所述软件表示形式看作初级组件。举例来说，组件的另一类别是SDK的接口定义文件。

单个组件CCR

如上所述，安装在档案中的每一开放式架构测试系统软件组件文件均伴随有组件配置记录(CCR)，其指定文件的属性。因此，配置控制下的TOS或.卖方文件在其安装到档案中时与CCR相关联。CCR是对安装在档案中的文件的描述，其中含有关于所述文件、其版本号、其相关联的组件、其相依性、其不兼容性等的信息。CCR用作对OCTool的输入；其允许用户查看、控制、跟踪和管理安装在测试系统中的所有组件。CCR的命名要求与其描述的相应系统文件的命名要求相同，区别在于需要强制附加扩展名.ccr。因此，文件AT_PinModule_0.5.1.dll的CCR命名为AT_PinModule_0.5.1.dll.ccr。请注意，已安装的CCR在<OASIS_ARCHIVE_ROOT>/InstallCCRs中完整地保存为安装的原始参考。CCR文件与组件文件(组件文件相对于档案目录而存储)放置在相同的目录位置中，但是相对于InstallCCR目录而放置。

群组CCR

可将CCR表示为参考一个以上CCR的群组——事实上，这是CCR通常借以引入到系统中的主要方法，因为其自然地映射以产生发布程序包。必要时，用户还可选择整个CCR群组以包含在简档中。

存在开放式架构测试系统安装所需要的一些重要的群组CCR。除了每一安装的开放式架构测试系统软件组件文件的CCR之外，还需要以下发布群组CCR：

由TOS供应方/系统集成器提供的开放式架构测试系统的TOS发布版本CCR；

由系统集成器或UserSDK供应方提供的开放式架构测试系统的UserSDK发布版本CCR；

由系统集成器或VendorSDK供应方提供的开放式架构测试系统的VendorSDK发布版本CCR。

群组CCR使用以下群组/文件命名格式：

VendorID_GroupType[_UserGivenName]_VersionIdentifier.gccr.

UserGivenName是可选的。

命名为OAI_TOS_<version>.gccr的TOS发布版本CCR是描述开放式架构测试系统TOS运行时间的总体发布版本的内容的群组CCR，其名义上标记为“<version>”发布版本。请注意，如上所定义，<version>是VersionIdentifier。其含有对共同定义开放式架构测试系统TOS运行时间的“<version>”发布版本的所有各个组件CCR的参考。此CCR的类型是“TOS”。

类似地，用户SDK发布版本CCR和卖方SDK发布版本CCR—分别为OAI_USER_SDK_<version>.ccr和OAI_VENDOR_SDK_<version>.gccr——是描述开放式架构测试系统用户和卖方SDK的总体发布版本的内容的群组CCR，且分别为用户_SDK类型和卖方_SDK类型。

除了以上要求的群组CCR之外，硬件模块卖方还可选择提供群组CCR以控制相关组件的发布版本。这些群组CCR为“卖方”、“用户”和“工具”类型。

单个组件CCR中的信息

如先前所提及，开放式架构测试系统中的初级组件是硬件模块的软件表示形式。CCR的信息内容负责指定支持此类初级组件所必需的所有属性，此类初级组件是所有组件类别中最复杂的。这些属性通常对于其它较简单的组件类别并不必要，无需对于上述组件类别定义这些属性的值。

CCR中含有的信息如表3中所示。对于支持开放式架构测试系统初级组件的CCR来说，提供此信息是硬件模块卖方的责任。

CCR字段	说明	必需
			描述	提供对此组件的简要描述的字符串	否

CCR字段	说明	必需
			卖方名称	提供此组件的卖方名称的字符串	是

CCR字段	说明	必需
			卖方ID	此组件的开放式架构测试系统的卖方识别符。所述ID与开放式架构测试系统的测试环境文件认可的识别符集合匹配。	是
模块名称	提供与此组件相关联的开放式架构测试系统的硬件模块(如果存在的话)的名称的字符串。	否
			模块ID	与此组件相关联的开放式架构测试系统的硬件模块识别符(如果存在的话)。所述ID与开放式架构测试系统的测试环境文件认可的识别符集合匹配。	否
文件参数	当系统加载CCR所对应的文件时，如果所述文件是可执行文件(例如，EXE或DLL)，那么会传达给所述文件的参数(如果存在的话)。	否
			功能	以下内容中的一者或一者以上的列表：驱动器、校准、诊断、仿真器、GPIB、RS232或图案编译器。如果此文件是与硬件模块的软件控制相关联的可执行文件，那么这指示此文件的初级功能。还需要用校准功能来提供为到达与此特定校准DLL相关联的校准程序算法版本信息文件的路径命名的参数。	否

CCR字段	说明	必需
			资源	文件(CCR所对应的文件)所控制的开放式架构测试系统资源(如果存在的话)连同其单元计数的列表。因此，此字段对于针对具有驱动器或仿真器功能性的文件的CCR有效。	否

CCR字段	说明	必需
			硬件修订版本	驱动器、校准、诊断、仿真器或图案编译器文件被指定进行协作的硬件组件版本(即，板版本)的列表。	否
部署到	“SYSC”、“SITEC”或“两者”中的一者，其指示CCR所对应的文件应在激活期间拷贝到的位置(不必要是其在运行时间可能最后处于的位置)	是
			寄存器	“调试”、“发布”或“两者”中的一者，其指示向Windows系统注册表注册文件属性是否必要。这一字段适用于可执行文件的CCR；假定的标准注册机制(在非“否”情况下)是使用具有提供DLL寄存器()方法的DLL的regsvr32，而EXE提供“/register”和“/unregister”命令线选项。	否
群组相依性	相依的发布群组CCR名称的列表。有效格式是VendorID_GroupType[_UserGivenName]_<Version>。	否

CCR字段	说明	必需
			组件相依性	相依的组件名称的列表。有效格式是VendorID_ComponentName_<Version>[.ext]	否
群组不兼容性	不兼容的发布群组CCR的列表。有效格式是VendorID_GroupType    [_UserGivenName]([＜，＜＝，＞，＞＝]<Version>)	否
			组件不兼容性	不兼容的组件CCR的列表。有效格式是VendorID_ComponentName[.ext]([＜，＜＝，＞，＞＝]<Version>)	否
组件类型	“Doc”、“Src”或“Bin”中的一者，其指示组件对应于哪种类型。“Doc”对应于文档类型。“Src”对应于源类型。“Bin”对应于二进制类型。	否

表3.单个组件CCR的信息内容

以下给出对于卖方数字引脚模块的驱动器DLL的简单的单个组件CCR文件的实例：

版本1.0；

描述             “Advantest数字引脚模块驱动器”；

卖方名称         AT；

卖方ID            1；

模块名称          DM250MHz；

模块ID            4；

文件参数          ″″；

功能              驱动器；

资源              “moduletrigger{MaxAvailable＝4；}”，

                  “dpin{MaxAvailable＝32；}″；

硬件修订版本      1095188784；

部署到            SYSC；

寄存器           “N”；

群组相依性        AT_VENDOR_Modules_1.0.1.0，

                  AT_Tools_GemTools_1.0.1.0；

群组不兼容性      OAI_TOS(＜0.5.0)；

组件不兼容性      AT_PinModule.dll(＜0.5.0)；

组件类型          Bin；

接下来是相同卖方数字引脚模块的校准DLL的单个组件CCR文件的实例：

版本1.0；

描述              “Advantest数字引脚模块校准DLL”；

卖方名称          AT；

卖方ID            1；

模块名称          DM250MHz；

模块ID            4；

文件参数          ″″；

功能              校准

                  [cfg/AT/AT_Cal_DM250MHz_0.5.021.algver.ini]；

硬件修订版本      1095188784；

部署到            SYSC；

寄存器            N；

群组不兼容性      OAI_TOS(＜0.5.0)；

请注意，版本指示CCR描述语言的版本，且不必要与其所描述的任何组件的版本有关。以上第一实例中的资源字段指示此模块驱动器(针对DM250MHz硬件模块)能够驱动提供4个单位的模块触发资源和32个单位的d引脚资源的硬件模块。参数“cfg/AT/AT_Cal_DM250MHz_0.5.021.algver.ini”(针对第二实例中指定为校准的功能)指定含有校准程序算法版本信息的文件的路径名称。这在输入到配置数据库(CDB)中之后由OCTool使用以产生校准束信息。每一实例中的群组非兼容性字段的值“OAI_TOS(＜0.5.0)”指示CCR所描述的DLL与版本号低于0.5.0的TOS发布群组CCR中包含的开放式架构测试系统的TOS组件不兼容。

群组CCR中的信息群组CCR是描述各个组件的集合的CCR，或其它群组CCR。表4中展示群组CCR中含有的信息。

CCR字段	说明	必需
			描述	提供对此CCR所代表的组件群组的简要描述的字符串。	是

CCR字段	说明	必需
			卖方名称	提供此群组的卖方的名称的字符串。	是
卖方ID	此群组的开放式架构测试系统的卖方识别符。所述ID与开放式架构测试系统的测试环境文件认可的识别符集合匹配。	是
			OAIMCF版本	此组件集合所兼容的开放式架构测试系统模块配置文件(MCF)的文件规范语言的版本，这是TOS发布版本CCR所必需的。	否
OAISim版本	此组件集合所兼容的开放式架构测试系统模拟配置文件(SCF)的文件规范语言的版本，这是TOS发布版本CCR所必需的。	否
			OAIOCF版本	此组件集合所兼容的开放式架构测试系统脱机配置文件(OCF)的文件规范语言的版本，这是TOS发布版本CCR所必需的。	否
组件	构成此群组的各个组件CCR的列表。	是

表4.群组CCR的信息内容

以下是用于开放式架构测试系统的TOS发布版本的群组CCR的实例：

版本1.0；

组件群组OAI_TOS_1.1.0.029。

   {

    描述             “开放式架构测试系统TOS发布程序包”；

    卖方名称AT；

    卖方ID 1；

    OAIMCF版本“＞＝1.0”；

    OAISim版本“＞＝0.9.5”；

    OAIOCF版本“＞＝1.0.1”；

    组件

    {

        bin/OAI/OAI_Core_0.4.9.dll.ccr；

        bin/OAI/OAI_StdProxy_0.3.7.dll.ccr；

        …

    }

}

输入群组CCR

除了描述群组之外，群组CCR还可输入其它群组CCR。以下是输入群组CCR的实例。

版本1.0；

输入        OAI_USERSDK_1.0.0.1；

组件群组    OAI_TOS_1.1.0.029

{

    描述           “开放式架构测试系统的TOS发布程序包”；

    卖方名称AT；

    卖方ID 1；

    OAIMCF版本“＞＝1.0”；

    OAISim版本“＞＝0.9.5”；

    OAIOCF版本“＞＝1.0.1”；

    组件

    {

        bin/OAI/OAI_Core_0.4.9.dll.ccr；

        bin/OAI/OAI_StdProxy_0.3.7.dll.ccr；

        …

    }

}

(配置数据库)

ICM配置数据库(CDB)保存通过所有安装的CCR所代表的系统配置数据的集合。CDB还保存用户创建的系统简档信息。在CDB中管理的信息独立于任何特定的测试器安装。

创建CDB和将CCR数据输入到其中是由开放式架构测试系统的CDBMgr工具来处理的。CDBMgr工具无需在测试器上安装或运行，且其所操纵的信息并不专用于特定测试器。然而，其需要访问根目录在$OASIS_ARCHIVE_ROOT处的目录树，因为其需要读取存储在所述树内的CCR文件(输入功能)。

使用CDB中的信息来创建系统简档，所述系统简档也存储在CDB中，且接下来将对其进行描述。

(系统简档)

以下要求指定系统简档：

由用户选择的开放式架构测试系统的系统简档是定义需要在开放式架构测试系统上工作的特定开放式架构测试系统软件配置所必需的信息的总体集合。

系统简档并不含有专用于任何特定测试器的信息；事实上，其概述所有必要的信息，以及由用户选择以供在测试器上激活的以下软件组件集合之间的相互依赖性。

硬件模块相关软件(例如，驱动器、仿真、校准和诊断组件)，

开放式架构测试系统运行时间软件，

用户SDK组件(测试开发环境所需的)，和

卖方SDK组件(模块开发环境所需的)

请注意，虽然将用户创建的系统简档信息存储在CDB中，但(通过OCTool)输出系统简档的动作促使创建含有定义简档的所有有关的独立于测试器的信息的文件，从而使得可在CDB外部获得简档。于是，其可由开放式架构测试系统的激活程序使用。将存储有简档信息的文件命名为OASISVer.cfg，其是标准的windows INI文件格式，且其默认存储在相应的$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>目录中。然而，虽然输出简档，但用户可选择将文件放置在其选择的任何位置中。

在激活期间，将用户简档中存储的独立于测试器的信息与测试器专用信息组合，以形成测试器的有效配置，其包括存储在$OASIS_ACTIVE_CONFIGS中的一组测试环境文件。以下部分中描述激活，在激活过程中重新访问系统简档。

(OCTool)

一旦开放式架构测试系统的CDB中充满了CCR数据，就使用配置工具(OCTool)来创建、保存、修改和输出(即，使得在CDB外部可用)用户创建的系统简档。

OCTool无需在测试器上安装或运行，且其所操纵的信息并不专用于特定测试器。然而，其需要访问根目录在$OASIS_ARCHIVE_ROOT处的目录树，因为其需要将用户简档信息保存到$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>(输出功能)。

激活

以下要求指定开放式架构测试系统的软件系统激活。激活开放式架构测试系统的软件系统是以下动作：

1.使用选定系统简档中的独立于测试器的配置信息，

2.将其与测试器专用信息组合，以在$OASIS_ACTIVE_CONFIGS中创建测试器有效配置信息，

3.将所有必需的软件组件(文件)部署(即，放置和注册)在$OASIS_INSTALLATION_ROOT下，

4.且在目标测试器上用选定配置来启动开放式架构测试系统的TOS。

激活开放式架构测试系统的软件系统是开放式架构测试系统的测试器控制后台程序(TCD)的功能。如上所述，TCD提供允许连接的应用程序发送测试器控制命令的COM接口方法。请记住，安装在<MAINTENANCE_ROOT>/bin中的TCD控制器应用程序是可向TCD发送基本的测试器系统控制命令(例如“启动”、“停止”、“激活”等)的简单的命令线应用程序。还应记住，这是Advantest T2000系统中的t2kctrl应用程序。在此部分中，描述用以执行“激活”功能的t2kctrl应用程序的使用。

(先决条件)

在试图(通过选定的简档)激活特定的开放式架构测试系统配置之前，必须满足以下先决条件：

1.$OASIS_ARCHIVE_ROOT所指定的位置可由在目标测试器机器的系统控制器上运行的TCD访问。

2.已将先前定义的开放式架构测试系统的系统简档输出到OASISVer.cfg中，且可在$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>或用户选择的另一位置处使用，且输出的文件OASISVer.cfg可由在目标测试器机器的系统控制器上运行的TCD访问。

3.已定义环境变量OASIS_INSTALLATION_ROOT和OASIS_TEMP。请注意，如果开放式架构测试系统的系统软件的另一配置已可在由$OASIS_INSTALLATION_ROOT指向的位置处使用，那么将安装备份到${OASIS_INSTALLATION_ROOT}_BAK，且激活程序如果成功的话会将选定的新配置放置在$OASIS_INSTALLATION_ROOT下。

4.已定义环境变量OASIS_ACTIVE_CONFIGS。请注意，如果此目录已经存在，且开放式架构测试系统的系统软件的另一组有效配置信息在所述位置处已经可用，那么将所述安装备份到${OASIS_ACTIVE_CONFIGS}_BAK，且激活程序如果成功的话会在$OASIS_ACTIVE_CONFIGS下创建对应于选定的新的有效配置的测试环境文件。

5.已定义环境变量OASIS_MACHINE_DIR^*。请注意，如果此目录已经存在，那么从目录$OASIS_MACHINE_DIR/CD/bundles中去除任何现存的校准/诊断(CD)束描述文件，并且与选定简档相关联的CD束描述文件安装在所述位置处。

6.系统控制器上存在测试器工厂默认(FDEF)文件<MAINTENANCE_ROOT>/cfg/OASISHW.def。此文件是向激活程序提供测试器专用信息所必需的。

7.开放式架构测试系统处于状态n(n＞0)，即，至少位于目标机器的系统控制器上的TCD正在运行。如果其不在运行，那么应当通过发布命令“net start T2000Svc”来使其启动。

(使用t2kctrl应用程序)

可使用以下命令来调用来自目标机器的系统控制器的激活程序：

t2kctrl switch<config><archive-location><profile-directory-name>

其中

<config>应当是“调试”或“发布”中的一者，其指示应安置的软件的建立模式。

<archive-location>应指定由环境变量OASIS_ARCHIVE_ROOT指向的位置的完整路径名称。

<profile-directory-name>应指定输出的简档信息所位于的简档目录的完整的路径名称。

(激活程序)

一旦已发布了合适的命令，那么激活程序如下：

1.如果测试器处于状态≥2(见第9页)，那么系统控制器TCD首先发布最终将系统带到状态1的TOS“关闭”命令。如果此时有任何开放式架构测试系统应用程序连接到系统控制器，那么向其发送消息要求其解除连接，并为其留出充足的时间来清除其状态并从容退出，或者另外强制使其终止。请注意，这并不适用于此时未连接到系统控制器的应用程序。

2.一旦系统处于状态1，那么将$OASIS_INSTALLATION_ROOT处的当前安装(如果存在的话)备份到${OASIS_INSTALLATION_ROOT}_BAK，且将已向Windows注册表(见表7中的“寄存器”字段)注册的所有开放式架构测试系统可执行文件解除注册。针对系统控制器以及所有现场控制器进行此操作。

3.接着，将$OASIS_ACTIVE_CONFIGS中的当前有效配置信息备份到${OASIS_ACTIVE_CONFIGS}_BAK，且删除$OASIS_MACHINE_DIR/CD/bundles中的CD束描述文件(如果存在的话)。

4.在已成功完成当前安装和有效配置信息的备份(必要时)之后，TCD将选定(新)简档所指定的存档的开放式架构测试系统的软件系统文件拷贝到下一部分中指定的位置。在分布式环境(单独的系统和现场控制器)中，也将必需安装在现场控制器上的文件拷贝到那些机器上。

5.接着，TCD在系统控制器和现场控制器两者上注册所有需要向Windows注册表注册的开放式架构测试系统可执行文件。

6.接着，TCD将来自选定(新)简档的独立于测试器的信息与来自测试器工厂默认文件(位于系统控制器上的<MAINTENANCE_ROOT>/cfg目录中)的测试器专用信息组合。这导致创建以下组文件，其定义目标测试器机器上的新开放式架构测试系统软件运行时间安装的有效配置：

模块配置文件，OASISModules.cfg。

模拟配置文件，OASISSim.cfg。

系统配置文件，OASISSys.cfg。

脱机配置文件，OASISOffline.cfg。

这些文件由TCD放置在$OASIS_ACTIVE_CONFIGS中。

7.TCD还将新简档信息文件OASISVer.cfg  的副本放置在$OASIS_ACTIVE_CONFIGS位置中，以用作按照新简档对系统的内容和配置的记录。

8.最后，TCD遵照TOS启动过程的步骤0-0中概述的TOS“启动”序列，以在新配置中启动TOS，因此完成激活程序。

请注意，未能成功地执行以上步骤中的任何步骤均会促使开放式架构测试系统安装回复到发布激活命令之前其处于的配置，且促使TCD在所述配置中重新启动TOS。此外，在位置$OASIS_INSTALLATION_ROOT/logs/Deployment中保存整个过程的详细日志。所述日志命名为Deployment.log，且每次新调用TCD的“激活”命令时便被覆写掉。

(部署目录结构)

如先前所提及，TCD将所需的开放式架构测试系统的软件文件从其在$OASIS_ARCHIVE_ROOT下的存档位置拷贝到目标测试器上的部署或运行时间安装，在$OASIS_INSTALLATION_ROOT处。

图6、图7和图8中展示测试器上的开放式架构测试系统部署的目录结构，其根目录位于$OASIS_INSTALLATION_ROOT处。激活程序遵照以下规定：

如图6、图7和图8中展示且如表8中描述，在$OASIS_INSTALLATION_ROOT下的适当位置中部署所有开放式架构测试系统软件组件文件，以便激活测试器机器上的运行时间。

在下图中，命名为OAI的目录含有开放式架构测试系统的TOS文件，而命名为<vendor>的目录含有卖方专用文件。如在档案结构中一样，每一卖方均具有其自身的目录，其中<vendor>指示唯一的两个到三个字母的识别符(例如：将Advantest卖方目录标记为AT)。

表5进一步描述上图中概述的目录结构，其中第一列中的每一目录相对于$OASIS_INSTALLATION_ROOT。

目录	说明
		./bin./cache./cfg./doc./logs	含有运行时间所使用的所有可执行文件(DLL和EXE)。请注意，在此下面没有子目录：所有文件均放置在相同层级上。这便于在系统运行时间需要对用户的系统“路径”环境变量进行最少量的操纵。还请注意，所有原本存档在$OASIS_ARCHIVE_ROOT/{Vendor，User}SDK/b下的可执行文件也部署在此目录处。含有TOS所需要的文件的运行时间缓存。含有系统TOS或卖方组件或者系统和卖方工具使用的配置文件，其中将系统和卖方工具组织成工具专用的(<tool>)子目录。共同子目录旨在由卖方用来放置需要在TOS和一个以上卖方的组件之间共享的配置信息。含有根据文档类别分成目录的文档。安装程序在将文件加载到档案中时记录其操作的位置。

目录	说明
		./{User，Vendor}SDK/doc./{User，Vendor}SDK/examples./{User，Vendor}SDK/inc./UserSDK/inc/STL./{User，Vendor}SDK/lib./UserSDK/templates./UserSDK/TestClasses	含有根据文档类别分成目录的SDK文档。基本目录含有index.html文件，其用作基本目录下的所有基于HTML的文档的顶级索引，所述文档根据主题组织在<html-dirs>中。用于存储SDK实例的位置。用于存储内含文件的位置。用于存储C++标准模板库(STL)文件层级的位置。用于存储库文件的位置。用于存储用户SDK所需的模板文件的位置。OAI/OTPL子目录用于存储OTPL编译器occ使用来进行其操作的模板。用于存储开放式架构测试系统的测试分类的位置。

表5.开放式架构测试系统部署目录结构

文件名转换

在激活期间，当将文件从档案部署到运行时间环境时，TCD会去掉嵌入在文件名中的版本识别符。因此，例如，将档案中的文件OAI_utils_0.1.2.dll拷贝到运行时间安装中的文件OAI_utils.dll，而将档案中的文件AT_Cal_DM250MHz_D_1.2.3.dll拷贝到运行时间安装中的文件AT_Cal_DM250MHz_D.dll。

(有效测试器配置)

如激活程序中所述，在目标测试器机器上部署开放式架构测试系统期间，TCD将来自选定(新)简档的独立于测试器的信息与来自FDEF文件的测试器专用信息合并。这导致创建以下组文件，其定义目标测试器机器上的新开放式架构测试系统软件运行时间安装的有效配置：

模块配置文件，OASISModules.cfg.

模拟配置文件，OASISSim.cfg.

系统配置文件，OASISSys.cfg.

脱机配置文件，OASISOffline.cfg.

TCD将这些文件放置在$OASIS_ACTIVE_CONFIGS中。请注意，不应当将$OASIS_ACTIVE_CONFIGS设定到根目录在$OASIS_INSTALLATION_ROOT处的目录树内部的位置。

(开放式架构测试系统机器数据)

将测试器机器专用数据(例如，校准/诊断(CD)数据等)存储在系统控制器上，在环境变量OASIS_MACHINE_DIR所指向的位置下。除了数据之外，CD数据目录还含有子目录CD/bundles，其用来存储与当前部署(即，有效的)简档相关联的CD束描述文件。

请注意，OASIS_MACHINE_DIR位置中的数据组由用户完全保存，且用户负责使特定机器所需的适当数据组可用。然而，激活程序负责关于CD束描述文件的以下行为：

删除$OASIS_MACHINE_DIR/CD/bundles中的任何现存的CD束描述文件。接着，将新的选定简档的CD束描述文件部署到$OASIS_MACHINE_DIR/CD/bundles。

请注意，不应当将$OASIS_MACHINE_DIR  设定到根目录在$OASIS_INSTALLATION_ROOT处的目录树内部的位置。

审核

开放式架构测试系统的简档审核允许用户核实存储在CDB中的给定简档的内容。另一方面，开放式架构测试系统审核是指提供特定测试系统上的当前有效的软件和硬件组件的列表的动作。以下工具性程序可用于允许此项活动。

(简档审核)

通过两种不同的机制可使此审核对于独立于测试器的简档信息来说是可用的：

OCTool应用程序可显示已存储在CDB中的选定简档的内容。

将给定简档输出(在可实现所述简档的激活之前执行)到默认位置$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>(或用户选择的另一位置)的动作会创建文件OASISVer.cfg。文件的内容完整地描述选定的简档。由于文件是普通的文本且具有标准Windows INI文件格式，所以可扫描此信息以提供所要的审核功能性。请注意，在有效部署中，也使此文件在$OASIS_ACTIVE_CONFIGS处可用。

(系统审核)

系统审核可划分为两个部分：部署的软件审核和测试器硬件审核。

部署的软件审核

通过以下在开放式架构测试系统上满足的要求来辅助部署的软件审核：

目标测试器机器上的开放式架构测试系统的软件部署或激活的过程会创建普通文本部署日志，所述日志提供部署的软件组件的完整细节。这一日志将被命名为Deployment.log，且在系统控制器上<MAINTENANCE_ROOT>/logs/Deployment位置处可用。

由于日志文件是普通文本形式，所以可扫描其中的信息以提供所需的审核功能性。

测试器硬件审核

通过开放式架构测试系统上的TOS所满足的以下要求来促进测试器硬件审核：

每当启动TOS时，以开放式架构测试系统硬件清单(HWINV)文件格式写入模块细节信息。将其存储在文件OASISHW.inv中，使其在系统控制器上<MAINTENANCE_ROOT>/cfg位置处可用。

由于硬件清单文件是普通文本形式的，所以可扫描其中的信息以提供所需的审核功能性。

软件修补程序发布版本

如上文新组件版本安装部分中所述，安装程序包可含有旨在修改或增强组件的当前发布版本的单个组件。当此种安装程序包与其旨在修改的发布版本的主要/次要版本兼容时，将程序包(及其通过扩展名而涉及的发布版本)称为“修补程序”。在此部分中，描述提供此修补程序发布版本时执行的步骤。

当发布组件的新版本时，组件供应方(TOS或卖方)提供新组件版本的CCR。如文件命名要求部分中所述，组件组成部分的文件名反映组件的新版本；遵照文件命名原则会防止覆写掉现存文件。因此，组件文件版本继续积累在档案目录中。由于现存组件的新版本不会取代现存的组件/文件，所以任何预先存在的系统简档均可能仍然运行。

(提供修补程序发布版本)

用于提供修补程序发布版本的步骤如下：

1.提供方(TOS供应方、卖方或系统集成器)识别并创建旨在修改或增强当前发布版本的组件(组)。举例来说，考虑包括OAI_core.dll和OAI_messages.dll的更新版本的TOS修补程序，其中当前发布的版本是OAI_core_1.2.9.dll和OAI_messages_1.2.2.dll。使当前发布版本的TOS发布版本CCR为OAI_TOS_1.2.11.ccr。

2.给以上组中的每一组件指派一名称，其中在识别系统中的分版本的组件的主要.次要.修补三元组中有“修补”字段的更新。因此，我们上述实例中的经过更新的组件可命名为OAI_core_1.2.10.dll和OAI_messages_1.2.3.dll。

3.针对经更新的组件中的每一者创建新的修补CCR，从而反映经更新的版本的信息。因此，我们上述实例中的组件的经更新的CCR可为OAI_core_1.2.10.dll.ccr和OAI_messages_1.2.3.dll.ccr。

4.创建新的发布群组CCR来代替正用于当前发布版本的原始群组CCR。这一CCR含有用于经更新的组件的新CCR组(在我们的实例中，为OAI_core_1.2.10.dll.ccr和OAI_messages_1.2.3.dll.ccr)的经更新的参考，而对群组中所有其它组件的参考保持与用于当前发布版本的参考相同。还为这一新的群组CCR给定<version>号，其对于名义上识别正考虑的程序包的共同“<version>”发布版本的主要.次要.修补三元组中的修补字段具有更新。因此，在我们的实例中，这一新发布群组CCR可命名为OAI_TOS_1.2.11.ccr。

5.供应方创建开放式架构测试系统的档案安装程序包，其由经更新的组件、其经更新的各个CCR和整个程序包的新发布群组CCR组成。这一程序包作为经识别的组件的整合“修补程序”而传递。

(使用修补程序发布版本)

在用户端，安装、配置和激活修补程序的过程如下：

1.用户将修补程序程序包的内容安装在开放式架构测试系统安装档案位置。

2.用户通过以下方式为修补程序进行配置：首先重新调用其意图使用的简档，并对其进行修改(或使用其作为新简档的基础)以使用新发布群组CCR(且因此，使用经更新的组件的各个组件CCR)，并保存所得的经过修改的(或新的)简档。

3.最后，用户使用以上经过修改的(或新的)简档来使用t2kctrl工具激活修补程序。

(仅针对硬件的修补程序)

硬件供应方有时需要更新硬件版本，而无需更新相应的软件。在此情况下，软件的现存CCR并不含有新硬件版本的正确的兼容性信息。

仅针对硬件的修补程序(HOP)是指经更新的CCR的发布版本，其目的是更新硬件/软件兼容性关系。当将这些CCR输入到数据库中时，可用新的兼容性信息来更新简档。照常创建这些CCR，且可将所述CCR作为不具有任何软件的程序包来分配。当用户接收到这些新的CCR时，使用用于安装、配置和激活修补程序的过程来处理新的CCR。

将了解，以上为了清楚起见而进行的描述已参考不同的功能单元和处理器描述了本发明的实施例。然而，将了解，在不偏离本发明的情况下可使用不同的功能单元或处理器之间的功能性的任何合适的分配。举例来说，说明为由单独处理器或控制器执行的功能性可由相同的处理器或控制器来执行。因此，对特定功能单元的参考仅应视为对用于提供所述功能性的合适构件的参考，而不是表示严格的逻辑或实体结构或组织。

产业适用性

本发明可以任何合适的形式实施，所述形式包含硬件、软件、固件或这些的任何组合。也可视情况将本发明部分地实施为在一个或一个以上数据处理器和/或数字信号处理器上运行的计算机软件。本发明实施例的元件和组件可在实体上、功能上和逻辑上以任何合适的方式实施。事实上，可将功能性实施在单个单元中、在多个单元中或作为其它功能单元的一部分。由此，本发明可实施在单个单元中，或者可实体上和功能上分配在不同的单元和处理器之间。

相关领域的技术人员将认识到，可使用所揭示的实施例的许多可能的修改和组合，同时仍然使用相同的基本的基础机制和方法。已参考特定实施例编写了上述描述内容以进行解释。然而，并不希望以上说明性论述是详尽的或将本发明限制于所揭示的精确形式。根据以上教示，可能存在许多修改和变化形式。选择并描述所述实施例是为了解释本发明的原理及其实践应用，并使所属领域的其他技术人员能够最佳地利用本发明和各种实施例，并作出适合于所期望的特定用途的各种修改。

Claims (22)

1.一种用于管理模块化测试系统中的多个硬件测试模块版本、软件组件和测试器操作系统版本的方法，其中所述模块化测试系统包括用于控制至少一个现场控制器的系统控制器，且其中所述至少一个现场控制器控制至少一个硬件测试模块，所述方法包括：

将与所述模块化测试系统兼容的测试器操作系统版本安装在档案中；

将对应于所述硬件测试模块版本的卖方软件组件安装在所述档案中；

创建用于描述对应于所述硬件测试模块版本和所述测试器操作系统版本的卖方软件组件的系统简档；

为所述模块化测试系统选择系统简档，其中所述系统简档包含一组兼容的卖方软件组件和用于测试特定硬件测试模块版本的选定测试器操作系统；和

激活所述系统控制器和所述至少一个现场控制器上的所述选定测试器操作系统。

2.根据权利要求1所述的方法，其中安装卖方软件组件包括：

安装用于执行对所述测试器操作系统版本的一般控制的测试控制后台程序；和

安装测试器操作系统控制目录。

3.根据权利要求2所述的方法，其中安装测试器操作系统控制目录包括：

安装用于存储测试控制后台程序控制器应用程序及其相关联的动态链接库的bin目录；

安装用于存储关于所述测试器的工厂默认设置的配置文件的配置目录；

安装用于存储测试控制后台程序和工厂默认文档的文档目录；和

安装用于存储所述测试控制后台程序的操作的安装日志目录。

4.根据权利要求3所述的方法，其中所述安装日志目录包括：

拷贝到所述档案的每一文件的路径；和

拷贝到所述档案中或从所述档案中去除的文件的状态。

5.根据权利要求1所述的方法，其中安装卖方软件组件进一步包括：

安装单个组件配置记录；和

安装群组组件配置记录。

6.根据权利要求5所述的方法，其中所述单个组件配置记录包括：

软件组件的卖方名称；和

所述软件组件的卖方识别符。

7.根据权利要求5所述的方法，其中所述群组组件配置记录包括：

对所述群组组件配置记录所代表的组件群组的描述；

所述群组组件配置记录的卖方名称；和

所述群组组件配置记录的卖方识别符。

8.根据权利要求1所述的方法，其中所述系统简档包括：

所述硬件测试模块版本专用的软件组件；

用户软件开发工具包；和

卖方软件开发工具包。

9.根据权利要求8所述的方法，其中所述硬件测试模块版本专用的软件组件包括：

装置驱动程序；

仿真软件组件；

校准软件组件；和

诊断软件组件。

10.根据权利要求1所述的方法，其中激活所述选定的测试器操作系统包括：

初始化所述选定的测试器操作系统；和

部署从所述模块化测试系统的系统简档中选出的软件配置。

11.根据权利要求10所述的方法，其中初始化所述选定的测试器操作系统包括：

初始化所述系统控制器；

初始化所述现场控制器；和

根据所述模块化测试系统的系统简档来初始化用户应用程序。

12.根据权利要求10所述的方法，部署选出的软件配置包括：

将独立于测试器的配置信息与测试专用信息组合以创建测试器有效配置信息；

部署来自预定义的目录位置的软件组件；和

用所述特定硬件测试模块版本的所选软件配置来启动所述选定的测试器操作系统。

13.根据权利要求1所述的方法，其进一步包括：

核实新卖方软件组件版本与现存的测试器操作系统版本的兼容性。

14.一种用于管理多个硬件测试模块版本、软件组件和测试器操作系统版本的模块化测试系统，其包括：

系统控制器，其用于控制至少一个现场控制器；

至少一个现场控制器，其用于控制至少一个硬件测试模块；

与所述模块化测试系统兼容的测试器操作系统版本；

对应于所述硬件测试模块版本的卖方软件组件；和

系统简档，其用于描述对应于所述硬件测试模块版本和所述测试器操作系统版本的卖方软件组件。

15.根据权利要求14所述的系统，其中所述卖方软件组件包括：

测试控制后台程序，其用于执行对所述测试器操作系统版本的一般控制；和

测试器操作系统控制目录。

16.根据权利要求15所述的系统，其中所述测试器操作系统控制目录包括：

bin目录，其用于存储测试控制后台程序控制器应用程序及其相关联的动态链接库；

配置目录，其用于存储关于所述测试器的工厂默认设置的配置文件；

文档目录，其用于存储测试控制后台程序和工厂默认文档；和

安装日志目录，其用于存储所述测试控制后台程序的操作。

17.根据权利要求16所述的系统，其中所述安装日志目录包括：

拷贝到档案的每一文件的路径；和

拷贝到所述档案中或从所述档案中去除的文件的状态。

18.根据权利要求14所述的系统，其中所述卖方软件组件进一步包括：

单个组件配置记录；和

群组组件配置记录。

19.根据权利要求18所述的系统，其中所述单个组件配置记录包括：

软件组件的卖方名称；和

所述软件组件的卖方识别符。

20.根据权利要求18所述的系统，其中所述群组组件配置记录包括：

对所述群组组件配置记录所代表的组件群组的描述；

所述群组组件配置记录的卖方名称；和

所述群组组件配置记录的卖方识别符。

21.根据权利要求14所述的系统，其中所述系统简档包括：

所述硬件测试模块版本专用的软件组件；

用户软件开发工具包；和

卖方软件开发工具包。

22.根据权利要求21所述的系统，其中所述硬件测试模块版本专用的软件组件包括：

装置驱动程序；

仿真软件组件；

校准软件组件；和

诊断软件组件。

Images