WO2006062252A1 - Method and system for performing installation and configuration management of tester instrument modules - Google Patents
Method and system for performing installation and configuration management of tester instrument modules Download PDFInfo
- Publication number
- WO2006062252A1 WO2006062252A1 PCT/JP2005/023004 JP2005023004W WO2006062252A1 WO 2006062252 A1 WO2006062252 A1 WO 2006062252A1 JP 2005023004 W JP2005023004 W JP 2005023004W WO 2006062252 A1 WO2006062252 A1 WO 2006062252A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- tos
- vendor
- versions
- software components
- software
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 71
- 238000009434 installation Methods 0.000 title claims description 56
- 238000012360 testing method Methods 0.000 claims abstract description 230
- 230000003213 activating effect Effects 0.000 claims abstract description 8
- 230000008569 process Effects 0.000 description 34
- 238000001994 activation Methods 0.000 description 31
- 230000004913 activation Effects 0.000 description 22
- 238000012550 audit Methods 0.000 description 13
- 230000006870 function Effects 0.000 description 13
- 230000000694 effects Effects 0.000 description 9
- 230000007704 transition Effects 0.000 description 8
- 238000007726 management method Methods 0.000 description 7
- 230000008676 import Effects 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000011161 development Methods 0.000 description 4
- 238000011900 installation process Methods 0.000 description 4
- 238000000357 thermal conductivity detection Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 239000000470 constituent Substances 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 239000011159 matrix material Substances 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 239000000523 sample Substances 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 238000000638 solvent extraction Methods 0.000 description 2
- 241001347978 Major minor Species 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/3181—Functional testing
- G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/3181—Functional testing
- G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
- G01R31/318307—Generation of test inputs, e.g. test vectors, patterns or sequences computer-aided, e.g. automatic test program generator [ATPG], program translations, test program debugging
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/3181—Functional testing
- G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
- G01R31/318314—Tools, e.g. program interfaces, test suite, test bench, simulation hardware, test compiler, test program languages
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/3181—Functional testing
- G01R31/319—Tester hardware, i.e. output processing circuits
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/3181—Functional testing
- G01R31/319—Tester hardware, i.e. output processing circuits
- G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
- G01R31/31907—Modular tester, e.g. controlling and coordinating instruments in a bus based architecture
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/3181—Functional testing
- G01R31/319—Tester hardware, i.e. output processing circuits
- G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
- G01R31/31908—Tester set-up, e.g. configuring the tester to the device under test [DUT], down loading test patterns
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
Definitions
- the present invention relates to the field of testing integrated circuits.
- the present invention relates to a method and system for performing installation and configuration management of tester instrument modules.
- a major reason for the high cost of test equipment is the specialized nature of conventional tester architecture.
- Each tester manufacturer has a number of tester platforms that are not only incompatible across companies such as Advantest, Teradyne and Agilent, but also incompatible across platforms within a company, such as the T3300, T5500 and T6600 series testers manufactured by Advantest. Because of these incompatibilities, each tester requires its own specialized hardware and software components, and these specialized hardware and software components cannot be used on other testers.
- a significant effort is required to port a test program from one tester to another, and to develop third party solutions. Even when a third party solution is developed for a platform, it cannot be ported or reused on a different platform.
- the translation process from one platform to another is generally complex and error prone, resulting in additional effort, time and increased test cost.
- DUT device-under-test
- IC integrated circuit
- An open architecture test system provides a solution to the above problems of the traditional test system.
- An example of an open architecture test system is described in U.S. application no. 10/772,434, "Method and Structure to Develop a Test Program for Semiconductor Integrated Circuits", which is incorporated herein in its entirety by reference.
- the open architecture test system can be configured to support a wide variety of vendor hardware test modules and their corresponding DUTs.
- each vendor hardware test module may have multiple versions and each version of the vendor hardware test module may have its corresponding versions of software components.
- the versions of the tester operating systems, vendor hardware test modules, and software components need to work together seamlessly in order to run tests on the vendor hardware test modules. Therefore, there is a need for a modular test system that can manage multiple vendor hardware test module versions, software components versions, and TOS versions for testing DUTs using the wide variety of vendor hardware test modules.
- a method for managing multiple hardware test module versions, software components, and tester operating system (TOS) versions in a modular test system includes installing the TOS versions compatible with the modular test system in an archive and installing vendor software components corresponding to the hardware test module versions in the archive. The method further includes creating system profiles for describing vendor software components corresponding to the hardware test module versions and the TOS versions, selecting a system profile for the modular test system, where the system profile includes a set of compatible vendor software components and a selected TOS for testing a particular hardware test module version, and activating the selected TOS on the modular test system.
- a system for managing multiple hardware test module versions, software components, and tester operating system (TOS) versions includes a system controller for controlling at least one site controller, at least one site controller for controlling at least one hardware test module, test operating system versions compatible with the modular test system, vendor software components corresponding to the hardware test module versions, and a system profile for describing vendor software components corresponding to the hardware test module versions and the TOS versions.
- Figure Ia illustrates an open architecture test system according to an embodiment of the present invention.
- Figure Ib illustrates a method for managing multiple hardware test module versions, software components, and TOS versions in a modular test system according to an embodiment of the present invention.
- Figure 2a illustrates a TOS control and factory defaults directory structure according to an embodiment of the present invention.
- Figure 2b illustrates a state diagram of the open architecture test system according to an embodiment of the present invention.
- FIG. 3 illustrates a TOS installation directory structure according to an embodiment of the present invention.
- Figure 4 illustrates a user SDK installation directory structure according to an embodiment of the present invention.
- Figure 5 illustrates a vendor SDK installation directory structure according to an embodiment of the present invention.
- FIG. 6 illustrates a TOS deployment directory structure according to an embodiment of the present invention.
- Figure 7 illustrates a user SDK deployment directory structure according to an embodiment of the present invention.
- Figure 8 illustrates a vendor SDK deployment directory structure according to an embodiment of the present invention.
- FIG. Ia illustrates an open architecture system according to an embodiment of the present invention.
- a system controller (SysC) 102 is coupled to multiple site controllers (SiteCs) 104.
- the system controller may also be coupled to a network to access files.
- a module connection enabler 106 each site controller is coupled to control one or more test modules 108 located at a test site 110.
- the module connection enabler 106 allows reconfiguration of connected hardware modules 108 and also serves as a bus for data transfer (for loading pattern data, gathering response data, providing control, etc.). Possible hardware implementations include dedicated connections, switch connections, bus connections, ring connections, and star connections.
- the module connection enabler 106 may be implemented by a switch matrix, for example.
- Each test site 110 is associated with a device under test (DUT) 112, which is connected to the modules of the corresponding site through a loadboard 114.
- DUT device under test
- the system controller 102 serves as the overall system manager. It coordinates the site controller activities, manages system-level parallel test strategies, and additionally provides for handler/probe controls as well as system-level data-logging and error handling support. Depending on the operational setting, the system controller 102 can be deployed on a CPU that is separate from the operation of site controllers 104. Alternatively a common CPU may be shared by the system controller 102 and the site controllers 104. Similarly, each site controller 104 can be deployed on its own dedicated CPU (central processing unit), or as a separate process or thread within the same CPU.
- system architecture can be conceptually envisioned as the distributed system shown in Figure Ia with the understanding that the individual system components may also be regarded as logical components of an integrated, monolithic system, and not necessarily as physical components of a distributed system.
- Figure Ib illustrates a method for managing multiple hardware test module versions, software components, and TOS versions in a modular test system.
- Multiple versions of the TOS and its associated versions of user and vendor SDKs, as well as multiple versions of Vendor Driver software are stored in an archive.
- the purpose of the open architecture test system Installation and Configuration Management (ICM) system is to allow Vendors to develop Driver software components to support their hardware modules and to allow users to select compatible Vendor Driver software and TOS versions for operation on a tester or development platform.
- the ICM system also manages installing these selected configurations on the tester or development platform and, optionally, activating the selected configurations.
- the ICM system describes the requirements for and activities involved in managing the open architecture test system's TOS.
- the ICM for an open architecture test system involves four principle activities:
- SW and HW are used to refer to software and hardware, respectively.
- the tester control and TOS startup section first provides a description of open architecture tester control and TOS system startup procedures. Also note that releases of open architecture test system software "patches" are an essential part of fixing and enhancing open architecture test system software components in- between more comprehensive software releases. Towards this end, the software patch releases section provides a description of the methods followed in creating, distributing and using open architecture test system software patch releases. (Tester Control and TOS Startup)
- TCD Tester Control Daemon
- Tester Control Daemon is responsible for the following functions:
- the system profile for an open architecture test system software configuration is described below, which is the total collection of information necessary to define a particular open architecture test system software configuration.
- the tester control daemon is referred to as used in a Windows operating system (OS); the concepts, however, are general and applicable to any open architecture test system.
- the TCD in a Windows system is a Win32 service (it appears in the list of installed services in the Services dialog box, available using the Windows Control Panel), that is installed and automatically run on the SysC and all SiteCs. It is a COM component that provides interface methods (on the System Controller side) to perform the above functions.
- main TCD is the one running on the System Controller
- auxiliary TCDs run on the Site Controllers, and are responsible for working under the aegis of the main TCD to bring up the individual Site Controllers.
- Every open architecture test system's System Controller and Site Controller is configured to have a TOS control and factory defaults directory structure, rooted at a location ⁇ MAINTENANCE_ROOT> that is available, and having a structure as shown in Figure 2a and described in Table 1.
- Table 1 describes the structure shown in Figure 2a. Note that the directories listed in the first column are relative to ⁇ MAINTENANCE ROOT>.
- the TCD controller application installed in ⁇ MAINTENANCE_ROOT>/bin is intended to be a simple command-line application that can send the basic tester system control commands, such as "start, "stop”, "activate”, etc. to the TCD.
- the Advantest T2000 system comes with the application t2kctrl to perform these ta.sks.
- ⁇ MAINTENANCE_ROOT>/cfg directory may vary from system integrator to system integrator; in each case, it contains tester information that is needed by the corresponding TCD or its installer to function.
- the Advantest T2000 tester system places the following information in ⁇ SystemDrive>:/T2000Maintenance/cfg.
- ⁇ SystemDrive> is an environment variable pre-defined by Windows; by default, it is "C:" on Windows 2000.
- the factory configuration of the Site Controllers (in a standard Windows INI file format) that specifies the internal system IP names and addresses of all the Site Controllers provided at the factory, together with any special open architecture test system user account and password information necessary for the open architecture test system software activation process to perform its duties.
- This file is named OASISSiteInfo.ini.
- the user may not modify this file on an online system.
- the user may modify this, if desired, from the default (which designates a single SiteC on the same machine as the SysC).
- the online mode need to use the original online factory configuration file (or one that has most recently been updated by a factory-authorized technician to reflect changes in the hardware layout).
- a factory defaults specification (FDEF) file containing information about overall tester properties, such as type, name, operating frequency, etc., the factory configured hardware modules and their board-specific details, the factory configured open architecture test system module connection enabler (MCE) ports the hardware modules are connected to, the open architecture test system synchronization matrix connections to each hardware module (if any), and the test head connections for the hardware modules.
- the user may not modify this file on an online system — modifications may only be made by authorized maintenance personnel who change the physical configuration of the machine.
- the factory defaults specification file defines a virtual machine configuration that is compatible with test examples provided, if any; the user may modify this, if desired, to configure his/her own virtual tester.
- the online mode need to use the original online factory configuration file (or one that has most recently been updated by a factory-authorized technician to reflect changes in the hardware layout).
- the TCD is responsible for starting the open architecture test system's TOS.
- TOS the mechanism of TOS bring-up
- FIGS The state transition diagram for an open architecture tester is shown in Figure 2b.
- State O The tester system is Idle: The TCD on the System Controller is not running and the TOS is not running.
- State 1 The TCD is running on at least the System Controller; however, the TOS is not yet functional.
- State 2 The open architecture test system's System Controller process is running, but has not yet been initialized; TCDs may or may not be running on all Site Controllers; in offline mode, the open architecture test system's tester emulator process is not yet running.
- State 3' ⁇ Offline mode only) The open architecture test system's tester emulator is running on the (single designated) Site Controller computer.
- State 3 At least Site Controller 1 (SITEC-I) has been successfully initialized, and the system is in default partitioned state (i.e., all hardware modules are connected, through the MCE, to SITEC-I); additionally, all designated Site Controllers may also have been successfully initialized. At this point, the system is "ready", i.e., configured to accept test plan load requests.
- State 4 A user test plan has been successfully loaded on one or more compatible Site Controllers, as part of which the system may have been (re)partitioned to accommodate the test plan requirements.
- initialization of the TOS System Controller process fails, i.e., it fails to start the open architecture test system's tester emulator process in the offline mode, or fails to start and initialize the TOS Site Controller process on at least SITEC-I. t(2, 3') (Offline mode only)
- the TOS System Controller process successfully starts the open architecture test system's emulator process on the (single designated) Site Controller computer.
- t(3', 3) * Offline mode only
- the TOS System Controller process successfully starts and initializes the TOS Site Controller process for at least SITEC-I (and possibly processes for all the designated Site Controllers).
- the TOS System Controller process fails to start and initialize the TOS Site Controller process for at least SITEC-I (the emulator process is terminated).
- the TOS System Controller process successfully starts and initializes the TOS Site Controller process on at least SITEC-I (and possibly on all the designated Site Controllers).
- t(3, 3) On receipt of a user command to load a user test plan, the TOS fails to load the specified test plan.
- t(3, 4) On receipt of a user command to load a test plan, the TOS successfully loads the test plan on the designated Site Controller(s), after successfully (re)partitioning the system (if necessary) as per the requirements of the socket associated with the specified test plan.
- t(4, 4) On receipt of a user command to (re)load (the same or a different) test plan, the TOS successfully (re)loads the test plan on the designated Site Controller(s), after successfully (re)partitioning the system (if necessary) as per the requirements of the socket associated with the specified test plan.
- t(3, 1) On receipt of a client command to "shutdown" the TOS, the TCD stops the
- the Windows service control manager starts the TCDs on the System and Site Controllers.
- the TCD on the System Controller verifies that a system profile is in effect, reads the profile-specified configuration of the Site Controllers — i.e., the file $OASIS_ACTIVE_CONFIGS/OASISSys.cfg — and starts the TOS System Controller process.
- the TCD then calls an initialize ⁇ ) method on the TOS System Controller process, which causes a.
- the tester emulator process to be started on the (single designated) Site Controller computer, if and only if the operation mode is offline; b.
- the TCD on each Site Controller to be requested to start its TOS Site Controller process; c.
- the TCD then attempts to start, in the order specified, any user applications listed for automatic startup in the currently active profile.
- a failure during any of the steps O O leads to the corresponding system state transition as described above.
- a failure at step O or O is logged in the Windows event log.
- a failure at step O is logged with the TOS System Controller process, and is made available for later retrieval by any client application that connects to it.
- the open architecture test system provides for users to add applications that should be started up automatically following a successful TOS startup.
- the OCTool allows users to specify their choices of such applications as part of a system profile.
- step O Ji(D is executed at the completion of a successful TOS initialization.
- the TCD reads a Startup section of the file OASISVer.cfg, which is the data file specifying the attributes of the chosen system profile, and is in standard windows INI file format. It treats each line in that section as a command line to launch a new application.
- a failure to launch any or all of the applications listed does not constitute an error condition as far as TOS bring-up is concerned, since applications are not part of the TOS. However, any such failures are noted and stored (for later retrieval by an application) in the TOS System Controller process.
- Installation for the open architecture test system comprises the installation of three main components, each of which is installed independently:
- TCD Tester Control Daemon
- the open architecture test system's TCD package is installed independently of any other open architecture test system component.
- the TCD package may typically be pre-installed.
- an installer may be provided by the system integrator.
- FDEF file with this one (if he wants to work with the open architecture test system examples).
- FDEF file does not exist, i. for an online system, a sample FDEF file is installed, and the user is warned to update it to be compatible with his installed hardware; ii. for an offline system, the pre-packaged version of this file is installed as the FDEF file (with the standard name as required by the open architecture test system)
- the installer installs the TCD binaries in ⁇ SystemRoot>/system32, and set Windows registry entries for any required COM component registrations.
- the installer sets the following configuration properties for the TCD: a. AutoStart: This specifies whether a Windows system boot causes the SysC TCD to automatically start the open architecture test system's TOS (TRUE) or not (FALSE). The default is TRUE; the person performing the installation may set it to FALSE, if desired. b. Mode: This specifies whether the TOS should be started in ONLINE (if applicable) or OFFLINE mode of operation. The default is ONLINE; and the person performing the installation may set it to OFFLINE, if desired. c. Configuration: This specifies whether the TOS should be started with DEBUG or RELEASE versions of components. The default is RELEASE; the person performing the installation may set it to DEBUG, if desired. 4. The installer installs the TCD controller application (t2kctrl), and its associated DLLs, in ⁇ MAINTENANCE_ROOT>/bin.
- the installer determines if it is already set, and, (ii) if not, sets it to a user-specified value: a. OASIS_INSTALLATION_ROOT b. OASIS_ACTIVE_CONFIGS c. OASIS_MACHINE_DIR d. OASISJTEMP
- StepO Jc(D) the TCD and the DLLs it depends on are installed in the Windows ⁇ SystemRoot>/system32 directory (which is ⁇ SystemDrive>/WINNT/system32 — most often, C:/WINNT/system32 — on Windows 2000), since that location assures proper operation of a Windows service.
- ⁇ MAINTENANCE_ROOT> needs to be present on the System and Site Controllers for the system to function properly.
- ⁇ MAINTENANCE_ROOT> (and the TCD and its related DLLs in ⁇ SystemRoot>/system32) should be carefully backed up and restored if one desires to reformat the local disk on which these components reside.
- the open architecture test system Configuration Tool, OCTool is distributed and installed in a separate package from the open architecture test system software.
- the installer for the OCTool allows the user to choose an installation location for the OCTool.
- the OCTool allows the user to create and save open architecture test system's system profiles that are tester-independent. Thus, one may conceptually install it in a location remote to any particular tester, as long as it had access to the archive location where the open architecture test system software is installed. However, one need to be careful not to install it in a location that lies within the directory tree rooted at $OASIS_INSTALLATION_ROOT, which is the root of the currently active system, since it may then be lost as a result of activating the system corresponding to a different profile.
- Installation of the open architecture test system software refers to the act of physically copying open architecture test system software components (ultimately, files) into a location defined by the operating-system environment variable OASIS_ARCHIVE_ROOT.
- This location is henceforth referred to as the archive.
- the archive contains files that are provided by open architecture test system's vendors and system integrators for users of the system. Note that this is distinct from the deployment or runtime location. In contrast to the deployment location, the archive location can physically be remote from the tester system, as long as it is accessible by the TCD, which runs on the tester system the software is deployed on.
- Open architecture test system software installation copies files into a defined archive location. This location is specified by the environment variable OASIS_ARCHIVE_ROOT.
- Each file installed to the archive is accompanied by a Component Configuration Record or CCR, which contains the required descriptive information for the file.
- the TOS and vendor files reside under a common root.
- these files to be managed via system profiles, they follow the open architecture test system file-naming requirements.
- the files on the system may be accumulated in a single archive directory for management. This applies for both TOS and vendor installed files.
- each component to be installed in an open architecture test system uses the following file-naming format, which prevents the names from colliding with those of other installed components from the same or different vendors:
- TOS and vendor components use the following naming format: VendorID_ComponentName_[D_JVersionIdentifier[.ext].
- VendorID A two to three-letter vendor identification code. This code distinguishes the component as a TOS or vendor-specific component, and provides for the disambiguation of files. Note that it is the responsibility of each vendor to manage the files they introduce into the system. The first character should be alphanumeric and can not be an underscore character. TOS runtime components use "OAI" as the identifier. The VendorID part is followed by an underscore character, '_'.
- ComponentName An arbitrary name as selected by component suppliers. The ComponentName part is followed by an underscore character, '_'.
- D This is optional, and applicable to executable components.
- ComponentName is followed by 'D', if and only if the component represents a debug dynamic link library (DLL) or executable (EXE).
- DLL debug dynamic link library
- EXE executable
- the absence of the 'D' implies that the component is a non-debug version (i.e. a "release" version). If present, the 'D' part is followed by an underscore character, '_'.
- Versionldentifier Explicit versioning of all files introduced into the system is a fundamental requirement. To be compatible across different operating systems, the versioning is represented as part of the filename, as the Versionldentifier field. This field has the following format: maj or .minor .patch where each of major, minor and patch are non-negative integer values, representing major minor and patch versions respectively of a component.
- Extensions are (optional) OS-specific identification aids, such as .dll, .exe, .txt, .doc, etc. Note that in all cases, the names of files are legal on all supported platforms (Windows, Linux, etc.). Some examples are as follows: AT_PinModule_10.01.008.dll AT_PinModule_l 0.01.008_D.dll AT_HCPowerSupplyModule_09.45.003.dll OAI_utils_00.03.000.dll
- the installation (i.e., archive) location is accessible from the tester system on which one wishes to activate the TOS.
- directories named OAI contain open architecture test system's TOS files, while directories named ⁇ vendor> contain vendor-specific files.
- Each vendor has its own directory, with ⁇ vendor> denoting a unique two to three letter identifier (e.g.: the Advantest vendor directory is labeled AT).
- the vendors are responsible for making sure that their filenames are unique. Also note that the requirement of explicit version identifiers in filenames allows different versions of the same component to be stored in the same location.
- Table 2 further describes the directory structure outlined in the above figures, where each directory in the first column is relative to $OASIS_ARCHIVE_ROOT.
- the directory logs contain the subdirectory Installer. This location supports the following specification:
- Installers for open architecture test system software create an installation log at a well-known location, namely, $OASIS_ARCHIVE_ROOT/logs/ ⁇ nstaller.
- the naming convention used for the TOS installation log file is OAI_ ⁇ vera7o «>.log. Vendor installers use the naming convention ⁇ vendor>_ ⁇ versiori>. log. Two further requirements are as follows:
- the installation log is a text file that explicitly shows the fully qualified path of each and every file copied to the archive. If an installer is run multiple times to add or remove components, the installation log is updated to show the current status of files copied to or removed from the archive.
- the component supplier When a new version of a component is released, the component supplier (TOS or vendor) provides a CCR for the new component version.
- the filenames of the component constituents reflect the new version of the component, as described in the file naming requirements section; following the file-naming rules prevents the overwriting of existing files.
- component file versions continue to accumulate in the archive directories.
- an installation package (as denoted by one of the release group CCRs described in below, or any vendor-provided release CCR for a direct vendor release) may contain individual components meant to fix or enhance a currently released version of a component. Since new versions of existing components do not replace existing components/files, any preexisting system profiles may still run. Note the following requirement for a patch for a component:
- Configuration refers to the act of allowing the user to interact with the ICM system to create, save and modify the open architecture test system software configuration as system profiles, which are later used for activation of particular configurations on a specific tester system. This section describes the mechanisms provided by the ICM to perform this function. (Components and Configuration Records)
- a component In an open architecture test system, a component is one or more files, environment settings, and etc. that represent a distinct module in the system.
- An important category of system components are software representations of system hardware modules, which are regarded as primary components.
- Another category of components for example, is an interface definition file for a SDK.
- each open architecture test system software component file installed in the archive is accompanied by a Component Configuration Record (CCR), which specifies the properties of the file.
- CCR Component Configuration Record
- a CCR is a description of a file installed in the archive, containing information about that file, its version number, its associated component, its dependencies, its incompatibilities, etc.
- the CCR serves as input to the OCTool; which allows the user to view, control, track, and manage all of the components installed in the test system.
- the naming requirements for a CCR are identical to those for the corresponding system file it describes, except that a mandatory additional extension of .ccr is required.
- the CCR for the file AT_PinModule_0.5.1.dll is named AT_PinModule_0.5.1.dll.ccr.
- installed CCRs are kept intact as the original reference of installation, in ⁇ OASIS_ARCHIVE_ROOT>/InstallCCRs.
- the CCR files are placed in the same directory location as the component files (component files are stored relative to archive directory), but relative to InstallCCR directory.
- CCRs can be represented as groups that reference more than one CCR — in fact, this is the principal method by which CCRs are often introduced into the system, since they naturally map to product release packages. The user can also choose an entire CCR group for inclusion in a profile, if necessary.
- the open architecture test system's TOS release CCR provided by the TOS supplier/system integrator;
- the open architecture test system's UserSDK release CCR provided by the system integrator or UserSDK supplier;
- the open architecture test system 's VendorSDK release CCR, provided by the system integrator or VendorSDK supplier.
- the group CCR' s uses the following group/file naming format:
- the TOS Release CCR is a group CCR describing the contents of an overall release of the open architecture test system TOS runtime, nominally labeled as the " ⁇ version>" release.
- ⁇ version> is the Versionldentifier, as defined in above. It contains references to all the individual component CCRs that collectively define the " ⁇ version>" release of the open architecture test system TOS runtime.
- the type of this CCR is "TOS”.
- OAI_USER_SDK_ ⁇ version>.ccr and OAI_VENDOR_SDK_ ⁇ version>.gccr respectively — are group CCRs describing the contents of overall releases of the open architecture test system user and vendor SDKs, and are of types "USER_SDK” and "VENDOR_SDK” respectively.
- group CCRs are of the type "VENDOR”, “USER”, and “TOOLS”.
- a primary component in the open architecture test system is the software representation of hardware modules.
- the information content of a CCR is oriented towards specifying all the attributes necessary to support such primary components, which are the most complex of all component categories. Such attributes are often not necessary for other, simpler categories of components, for which the values of such attributes need not be defined.
- CCR The information contained in a CCR is as shown in Table 3. For CCRs supporting open architecture test system primary components, it is the hardware module vendor's responsibility to provide this information.
- VendorID l
- VendorID l
- Version specifies the version of the CCR description language, and is not necessarily related to the version(s) of any component it describes.
- the Resource field in the first example above indicates that this module Driver (for the DM25 OMHz hardware module) is capable of driving a hardware module that provides 4 units of the moduletrigger resource, and 32 units of the dpin resource.
- the parameter "cfg/AT/AT_Cal_DM250MHz_0.5.021.algver.ini” (for the Function designated as Calibration in the second example) specifies the pathname of the file containing calibration program algorithm version information. This is used — after an import into the Configuration Database (CDB), by the OCTool to generate Calibration bundle information.
- CDB Configuration Database
- a group CCR is a CCR that describes a collection of individual component, or other group CCRs.
- the information contained in a group CCR is shown in Table 4.
- group CCRs can import other group CCRs.
- group CCRs can import other group CCRs.
- the following is an example to import group CCRs.
- the ICM Configuration Database maintains the collection of system configuration data represented through all installed CCRs.
- the CDB also maintains user-created system profile information.
- the information managed in the CDB is independent of any particular tester installation.
- the CDBMgr tool need not be installed or run on the tester, and the information it manipulates is not specific to a particular tester. However, it needs access to the directory tree rooted at $OASIS_ARCHIVE_ROOT, since it needs to read CCR files stored within that tree (the import function).
- An open architecture test system's system profile chosen by the user, is the total collection of information necessary to define a particular open architecture test system software configuration that is required to work on an open architecture test system.
- a system profile does not contain information specific to any particular tester; rather, it encapsulates all necessary information and inter-dependencies amongst the following set of software components chosen by the user for activation on a tester.
- hardware module-related software such as driver, emulation, calibration and diagnostics components
- open architecture test system runtime software such as test system runtime software
- user SDK components needed for a test development environment
- vendor SDK components needed for a module development environment
- the tester-independent information stored in a user profile is combined with tester-specific information to form the tester's active configuration, which comprises a set of test environment files stored in $OASIS_ACTIVE_CONFIGS. Activation is described in the following section, where the system profiles are revisited. (OCTool)
- the Configuration Tool is used to create, save, modify and export (i.e., make available external to the CDB) system profiles created by the user.
- the OCTool need not be installed or run on the tester, and the information it manipulates is not specific to a particular tester. However, it needs access to the directory tree rooted at $OASIS_ARCHIVE_ROOT, since it needs to save user profile information to $OASIS_ARCHIVE_ROOT/profiles/ ⁇ profile_dir> (the export function).
- TCD tester control daemon
- ⁇ MAINTENANCE_ROOT>/bin is a simple command-line application that can send the basic tester system control commands, such as "start”, “stop”, “activate”, etc. to the TCD. Also recall that this is the t2kctrl application in the Advantest T2000 system. In this section, the use of the t2kctrl application to perform the "activate" function described. (Prerequisites)
- a previously-defined open architecture test system's system profile has been exported into OASISVer.cfg, and is available at either $OASIS_ARCHIVE_ROOT/profiles/ ⁇ profile_dir>, or another location/ of the user's choice, and the exported file OASISVer.cfg is accessible to the TCD running on the target tester machine's System Controller.
- the environment variable OASIS_ACTIVE_CONFIGS has been defined. Note that if this directory already exists, and another set of active configuration information for open architecture test system's system software is already available at that location, that installation is backed up to $ ⁇ OASIS_ACTIVE_CONFIGS ⁇ _BAK, and the activation process, if successful, creates the test environment files corresponding to the chosen new active configuration under $OASIS_ACTIVE_CONFIGS.
- the environment variable O ASIS_MACHINEJDIR has been defined * . Note that if this directory already exists, the directory $OASIS_MACHINE_DIR/CD/bundles is purged of any existing calibration/diagnostic (CD) bundle description files, and the CD bundle description file(s) associated with the chosen profile is instated at that location.
- the open architecture test system is in State n, n > 0, i.e., at least the TCD on the System Controller of the target machine is running. If it is not, one should start it by issuing the command "net start T2000Svc".
- the following command may be used to invoke the activation process from the System Controller of the target machine: t2kctrl switch ⁇ config> ⁇ archive-location> ⁇ profile-directory-name> where ⁇ config> Should be one of DEBUG or RELEASE, indicating the build mode of the software that should be instated.
- ⁇ archive-location> Should specify the full pathname of the location pointed to by the environment variable OASIS_ARCHIVE_ROOT.
- ⁇ profile-directory-name> Should specify the full pathname of the profile directory in which the exported profile information is located.
- the System Controller TCD first issues a TOS "shutdown" command that ultimately brings the system to State 1. If any open architecture test system application is connected to the System Controller at this time, it is sent a message asking it to disconnect, and allowed sufficient time to clean up its state and exit gracefully, or forcibly terminated otherwise. Note that this does not apply to applications that are not connected to the System Controller at that time.
- the TCD copies the archived open architecture test system's software system files, as specified by the chosen (new) profile, over to the locations specified in the next section.
- the files required to be installed on the Site Controllers are also copied over to those machines.
- the TCD then registers all open architecture test system executables that are required to be registered with the Windows registry, on both System and Site Controller(s).
- the tester-independent information from the chosen (new) profile is then combined with the tester-specific information from the tester factory defaults file (located in the ⁇ MAINTENANCE_ROOT>/cfg directory on the System Controller) by the TCD. This results in the creation of the following set of files that define the active configuration for the new open architecture test system software runtime installation on the target tester machine: •
- the TCD also places a copy of the new profile information file, OASISVer.cfg, in the $OASIS_ACTIVE_CONFIGS location, to serve as a record of the contents and configuration of the system as per the new profile.
- the TCD follows the TOS "startup" sequence outlined in steps 0 — 0 of the TOS startup process to start the TOS in the new configuration, thus completing the activation process.
- the TCD copies the required open architecture test system's software files from their archived location under $OASIS_ARCHIVE_ROOT to the, deployment or runtime installation on the target tester, at $OASIS_INSTALLATION_ROOT.
- directories named OAI contain open architecture test system's TOS files
- directories named ⁇ vendor> contain vendor-specific files.
- each vendor has its own directory, with ⁇ vendor> denoting a unique two to three letter identifier (e.g.: the Advantest vendor directory is labeled AT).
- Table 5 further describes the directory structure outlined in the above figures, where each directory in the first column is relative to $OASIS_INSTALLATION_ROOT.
- the TCD strips off the version identifier embedded in the filenames.
- the file OAI_utils_0.1.2.dll in the archive is copied to the file OAI_utils.dll in the runtime installation
- the file AT_Cal_DM250MHz_D_1.2.3.dll in the archive is copied to the file AT_Cal_DM250MHz_D.dll in the runtime installation.
- the tester-independent information from the chosen (new) profile is merged with the tester-specific information from the FDEF file by the TCD.
- Tester machine-specific data such as calibration/diagnostics (CD) data, etc.
- CD calibration/diagnostics
- the CDdata directory contains the sub-directory CD/bundles, which is used to store the CD bundle description file(s) associated with the currently deployed (i.e., active) profile.
- a profile audit for the open architecture test system allows the user to verify the contents of given profile stored in the CDB.
- An open architecture test system audit refers to the act of providing a listing of currently active software and hardware components on a particular test system. The following facilities are available to allow this activity. (Profile Audit)
- the OCTool application can display the contents of a chosen profile that has been stored in the CDB.
- $OASIS_ARCHIVE_ROOT/proflles/ ⁇ proflle_dir> (or another location of the user's choice) creates the file OASISVer.cfg.
- the contents of the file completely describe the chosen profile. Since the file is in plain-text and in standard Windows INI file format, the information can be scanned to provide the desired audit functionality. Note that in an active deployment, this file is also made available at $OASIS_ACTIVE_CONFIGS. (System Audit)
- the system audit can be divided into two parts: deployed software audit, and tester hardware audit.
- the deployed software audit is facilitated through the following requirement that is satisfied on an open architecture test system:
- the log file Since the log file is in plain-text, the information in it can be scanned to provide the required audit functionality.
- the tester hardware audit is facilitated through the following requirement that is satisfied by the TOS on an open architecture test system:
- Module detail information is written in the open architecture test system Hardware Inventory (HWINV) file format each time the TOS is started. This is stored in the file O ASISHW. inv, made available on the System Controller at the location ⁇ MAINTENANCE_ROOT>/cfg.
- HWINV Hardware Inventory
- the hardware inventory file is in plain-text, the information in it can be scanned to provide the required audit functionality.
- an installation package may contain individual components meant to fix or enhance a currently released version of a component.
- the package (and, by extension, the release it pertains to) is referred to as a "patch".
- the steps performed in providing such a patch release is described.
- the component supplier When a new version of a component is released, the component supplier (TOS or vendor) provides a CCR for the new component version.
- the filenames of the component constituents reflect the new version of the component, as described in the file naming requirements section; following the file-naming rules prevents the overwriting of existing files.
- component file versions continue to accumulate in the archive directories. Since new versions of existing components do not replace existing components/files, any pre-existing system profiles may still run. (Providing a Patch Release)
- the provider identifies and creates the (set of) com ⁇ onent(s) that are meant to fix or enhance a current release.
- TOS supplier vendor or system integrator
- a TOS patch comprising updated versions of the OAI_core.dll and the OAI_messages.dll, where the currently released versions are OAI_core_1.2.9.dll and OAI_messages_l .2.2.dll.
- the TOS Release CCR for the current release be 0AI_T0S_1.2.11.ccr.
- Each component in the above set is assigned a name with an update of the "patch" field in the major. minor. patch triad that identifies the versioned component in the system.
- the updated components in our example above may be named OAI_core_1.2.10.dll and OAI_messages_1.2.3.dll. 3.
- a new patch CCR is created for each of the updated components, reflecting the updated version information.
- the updated CCRs for the components in our example above may be OAI_core_1.2.10.dll.ccr and OAI_messages_1.2.3.dll.ccr.
- a new release group CCR is created to replace the original group CCR that is being used for the current release.
- This CCR contains updated references for the set of new CCR(s) for the updated components (in our example, OAI_core_1.2.10.dll.ccr and OAI_messages_l .2.3.dll. ccr), while the references to all other components in the group stay the same as those for the current release.
- This new group CCR is also given a ⁇ version> number that has an update for the "patch" field in the major. minor patch triad that nominally identifies the collective " ⁇ version>" release of the package being considered.
- this new release group CCR may be named OAI_TOS_1.2.11.ccr.
- the supplier creates an open architecture test system's archive installation package consisting of the updated components, their updated individual CCRs, and the new release group CCR for the overall package. This package is delivered as an integrated "patch" for the identified components.
- the user installs the contents of the patch package into the open architecture test system installation archive location.
- the user configures for the patch by first recalling the profile he intends to use, and modifying it (or using it as the basis for a new profile) to use the new release group CCR (and thereby, the individual component CCRs for the updated components), and saving the resulting modified (or new) profile.
- Hardware suppliers occasionally need to update hardware versions without needing to update the corresponding software.
- existing CCRs for the software do not contain correct compatibility information for the new hardware versions.
- a Hardware-Only Patch refers to a release of updated CCRs whose purpose is to update hardware/software compatibility relationships. When these CCRs are imported into the database profiles may be updated with the new compatibility information.
- Such CCRs are created as usual and may be distributed as a package without any software. When users received these new CCRs, the procedures for installing, configuring, and activating the patch one used for handling the new CCRs.
- the invention can be implemented in any suitable form including hardware, software, firmware or any combination of these.
- the invention may optionally be implemented partly as computer software running on one or more data processors and/or digital signal processors.
- the elements and components of an embodiment of the invention may be physically, functionally, and logically implemented in any suitable way. Indeed the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the invention may be implemented in a single unit or may be physically and functionally distributed between different units and processors.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP05816758A EP1820036A1 (en) | 2004-12-09 | 2005-12-08 | Method and system for performing installation and configuration management of tester instrument modules |
JP2006515518A JP4302736B2 (en) | 2004-12-09 | 2005-12-08 | Method and system for performing tester equipment module installation and configuration management |
CN2005800418100A CN101073016B (en) | 2004-12-09 | 2005-12-08 | Method and system for performing installation and configuration management of tester instrument modules |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US63509404P | 2004-12-09 | 2004-12-09 | |
US60/635,094 | 2004-12-09 | ||
US11/100,109 US8082541B2 (en) | 2004-12-09 | 2005-04-05 | Method and system for performing installation and configuration management of tester instrument modules |
US11/100,109 | 2005-04-05 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2006062252A1 true WO2006062252A1 (en) | 2006-06-15 |
Family
ID=35911084
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2005/023004 WO2006062252A1 (en) | 2004-12-09 | 2005-12-08 | Method and system for performing installation and configuration management of tester instrument modules |
Country Status (7)
Country | Link |
---|---|
US (1) | US8082541B2 (en) |
EP (1) | EP1820036A1 (en) |
JP (2) | JP4302736B2 (en) |
KR (1) | KR20070106692A (en) |
CN (1) | CN101073016B (en) |
TW (1) | TWI383166B (en) |
WO (1) | WO2006062252A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2237125A1 (en) * | 2009-03-31 | 2010-10-06 | Siemens Aktiengesellschaft | Method of monitoring an analyser connected to a communications network in an industrial automation system and industrial automation system |
Families Citing this family (66)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8214800B2 (en) * | 2005-03-02 | 2012-07-03 | Advantest Corporation | Compact representation of vendor hardware module revisions in an open architecture test system |
US7930693B2 (en) * | 2005-04-04 | 2011-04-19 | Cisco Technology, Inc. | Method and system for accessing and launching a java based applet as a locally installed application |
US7877350B2 (en) | 2005-06-27 | 2011-01-25 | Ab Initio Technology Llc | Managing metadata for graph-based computations |
US20070074202A1 (en) * | 2005-09-27 | 2007-03-29 | International Business Machines Corporation | Program product installation |
US7730452B1 (en) * | 2005-11-01 | 2010-06-01 | Hewlett-Packard Development Company, L.P. | Testing a component of a distributed system |
US7849362B2 (en) * | 2005-12-09 | 2010-12-07 | International Business Machines Corporation | Method and system of coherent design verification of inter-cluster interactions |
US20070156641A1 (en) * | 2005-12-30 | 2007-07-05 | Thomas Mueller | System and method to provide system independent configuration references |
US7877680B2 (en) * | 2007-03-20 | 2011-01-25 | International Business Machines Corporation | Auto-generation and auto-versioning of a multi-sourced dynamic document |
US8423831B2 (en) * | 2006-07-11 | 2013-04-16 | Oracle America, Inc. | System and method for performing auditing and correction |
US20080172652A1 (en) * | 2007-01-15 | 2008-07-17 | Microsoft Corporation | Identifying Redundant Test Cases |
US20080172655A1 (en) * | 2007-01-15 | 2008-07-17 | Microsoft Corporation | Saving Code Coverage Data for Analysis |
US20080172651A1 (en) * | 2007-01-15 | 2008-07-17 | Microsoft Corporation | Applying Function Level Ownership to Test Metrics |
US20080172580A1 (en) * | 2007-01-15 | 2008-07-17 | Microsoft Corporation | Collecting and Reporting Code Coverage Data |
US7844602B2 (en) * | 2007-01-19 | 2010-11-30 | Healthline Networks, Inc. | Method and system for establishing document relevance |
CN101441595B (en) * | 2007-11-21 | 2010-11-03 | 英业达股份有限公司 | Load monitoring apparatus and test structure and load monitoring method and test method thereof |
US8219349B1 (en) * | 2007-12-21 | 2012-07-10 | Intermolecular, Inc. | Test management system |
US7680615B2 (en) * | 2008-01-25 | 2010-03-16 | Azurewave Technologies, Inc. | Parallel testing system with shared golden calibration table and method thereof |
CN105843684B (en) | 2009-02-13 | 2020-03-03 | 起元技术有限责任公司 | Managing task execution |
US9680964B2 (en) * | 2009-03-11 | 2017-06-13 | Microsoft Technology Licensing, Llc | Programming model for installing and distributing occasionally connected applications |
US8413139B2 (en) * | 2009-03-11 | 2013-04-02 | Microsoft Corporation | Programming model for application and data access and synchronization within virtual environments |
US8812451B2 (en) | 2009-03-11 | 2014-08-19 | Microsoft Corporation | Programming model for synchronizing browser caches across devices and web services |
KR101231746B1 (en) * | 2009-12-18 | 2013-02-08 | 한국전자통신연구원 | Software Development system in SaaS environment |
WO2011159759A1 (en) | 2010-06-15 | 2011-12-22 | Ab Initio Technology Llc | Dynamically loading graph-based computations |
CN103165405A (en) * | 2011-01-27 | 2013-06-19 | 北京确安科技股份有限公司 | Mutli-dimensional variable code real-time generation method through general purpose interface bus (GPIB) interface |
US20120198436A1 (en) * | 2011-01-27 | 2012-08-02 | Preimesberger Lee A | Compatible Operating System |
US8839057B2 (en) * | 2011-02-03 | 2014-09-16 | Arm Limited | Integrated circuit and method for testing memory on the integrated circuit |
US9116725B1 (en) * | 2011-03-15 | 2015-08-25 | Symantec Corporation | Systems and methods for using virtualization of operating-system-level components to facilitate software testing |
KR101056682B1 (en) | 2011-04-08 | 2011-08-12 | 국방과학연구소 | A weapon simulation system and the same method based on the component |
US8745590B2 (en) * | 2011-05-19 | 2014-06-03 | Verizon Patent And Licensing Inc. | Testing an application |
TWI476586B (en) * | 2011-07-13 | 2015-03-11 | Inst Information Industry | Cloud-based test system, method and computer readable storage medium storing thereof |
US8756595B2 (en) * | 2011-07-28 | 2014-06-17 | Yahoo! Inc. | Method and system for distributed application stack deployment |
TW201324354A (en) * | 2011-12-12 | 2013-06-16 | Wistron Corp | Method for automatic consecutive installing operating systems |
JP5816144B2 (en) * | 2012-08-30 | 2015-11-18 | 株式会社アドバンテスト | Test program and test system |
CN102866348A (en) * | 2012-09-23 | 2013-01-09 | 成都市中州半导体科技有限公司 | Integrated circuit test data query system and integrated circuit test data query method |
US9507682B2 (en) | 2012-11-16 | 2016-11-29 | Ab Initio Technology Llc | Dynamic graph performance monitoring |
US10108521B2 (en) | 2012-11-16 | 2018-10-23 | Ab Initio Technology Llc | Dynamic component performance monitoring |
US9632764B2 (en) * | 2012-12-31 | 2017-04-25 | Oracle International Corporation | Defining configurable characteristics of a product and associating configuration with enterprise resources |
US9274926B2 (en) * | 2013-01-03 | 2016-03-01 | Ab Initio Technology Llc | Configurable testing of computer programs |
US9218273B2 (en) | 2013-05-20 | 2015-12-22 | International Business Machines Corporation | Automatic generation of a resource reconfiguring test |
EP3092557B1 (en) | 2013-12-05 | 2024-03-27 | AB Initio Technology LLC | Managing interfaces for dataflow graphs composed of sub-graphs |
CN105527940A (en) * | 2014-10-27 | 2016-04-27 | 北京确安科技股份有限公司 | Method for realizing flow control of test management system via INI file |
US9292423B1 (en) * | 2015-03-11 | 2016-03-22 | Amazon Technologies, Inc. | Monitoring applications for compatibility issues |
JP6561555B2 (en) | 2015-04-20 | 2019-08-21 | 富士通株式会社 | Information processing apparatus, operation verification method, and operation verification program |
US10657134B2 (en) | 2015-08-05 | 2020-05-19 | Ab Initio Technology Llc | Selecting queries for execution on a stream of real-time data |
WO2017112654A2 (en) | 2015-12-21 | 2017-06-29 | Ab Initio Technology Llc | Sub-graph interface generation |
CN105786562A (en) * | 2016-02-04 | 2016-07-20 | 百度在线网络技术(北京)有限公司 | Method and device for integrating plug-in |
CN107577570A (en) * | 2017-09-19 | 2018-01-12 | 郑州云海信息技术有限公司 | The method of testing and device of a kind of application apparatus |
JP6960873B2 (en) * | 2018-03-16 | 2021-11-05 | 東京エレクトロン株式会社 | Semiconductor manufacturing system and server equipment |
US10430321B1 (en) * | 2018-08-21 | 2019-10-01 | International Business Machines Corporation | White box code concurrency testing for transaction processing |
US10320625B1 (en) | 2018-08-21 | 2019-06-11 | Capital One Services, Llc | Managing service deployment in a cloud computing environment |
CN109376048A (en) * | 2018-12-25 | 2019-02-22 | 上海创功通讯技术有限公司 | A kind of test method and equipment of touch screen |
CN111913869B (en) * | 2019-05-08 | 2024-02-13 | 立端科技股份有限公司 | Test method and test system for automatically testing host operating system |
TWI760691B (en) * | 2020-02-12 | 2022-04-11 | 瑞昱半導體股份有限公司 | Method, test device and system for automatically testing software compatibility |
US11733290B2 (en) | 2020-03-31 | 2023-08-22 | Advantest Corporation | Flexible sideband support systems and methods |
US11650893B2 (en) | 2020-03-31 | 2023-05-16 | Advantest Corporation | Multiple name space test systems and methods |
US11899550B2 (en) * | 2020-03-31 | 2024-02-13 | Advantest Corporation | Enhanced auxiliary memory mapped interface test systems and methods |
US11493551B2 (en) | 2020-06-22 | 2022-11-08 | Advantest Test Solutions, Inc. | Integrated test cell using active thermal interposer (ATI) with parallel socket actuation |
US11549981B2 (en) | 2020-10-01 | 2023-01-10 | Advantest Test Solutions, Inc. | Thermal solution for massively parallel testing |
US11808812B2 (en) | 2020-11-02 | 2023-11-07 | Advantest Test Solutions, Inc. | Passive carrier-based device delivery for slot-based high-volume semiconductor test system |
US11821913B2 (en) | 2020-11-02 | 2023-11-21 | Advantest Test Solutions, Inc. | Shielded socket and carrier for high-volume test of semiconductor devices |
US20220155364A1 (en) | 2020-11-19 | 2022-05-19 | Advantest Test Solutions, Inc. | Wafer scale active thermal interposer for device testing |
US11609266B2 (en) | 2020-12-04 | 2023-03-21 | Advantest Test Solutions, Inc. | Active thermal interposer device |
US11573262B2 (en) | 2020-12-31 | 2023-02-07 | Advantest Test Solutions, Inc. | Multi-input multi-zone thermal control for device testing |
US11587640B2 (en) | 2021-03-08 | 2023-02-21 | Advantest Test Solutions, Inc. | Carrier based high volume system level testing of devices with pop structures |
US11656273B1 (en) | 2021-11-05 | 2023-05-23 | Advantest Test Solutions, Inc. | High current device testing apparatus and systems |
CN115033466B (en) * | 2022-05-23 | 2023-04-07 | 珠海视熙科技有限公司 | Batch flashing pressure testing method and device, storage medium and computer equipment |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5450586A (en) * | 1991-08-14 | 1995-09-12 | Hewlett-Packard Company | System for analyzing and debugging embedded software through dynamic and interactive use of code markers |
US5903758A (en) * | 1997-02-24 | 1999-05-11 | Sun Microsystems, Inc. | Method and apparatus for auditing dynamically linked procedure calls |
US5960198A (en) * | 1997-03-19 | 1999-09-28 | International Business Machines Corporation | Software profiler with runtime control to enable and disable instrumented executable |
US6182275B1 (en) * | 1998-01-26 | 2001-01-30 | Dell Usa, L.P. | Generation of a compatible order for a computer system |
US6954922B2 (en) * | 1998-04-29 | 2005-10-11 | Sun Microsystems, Inc. | Method apparatus and article of manufacture for time profiling multi-threaded programs |
US6381735B1 (en) * | 1998-10-02 | 2002-04-30 | Microsoft Corporation | Dynamic classification of sections of software |
US6895578B1 (en) * | 1999-01-06 | 2005-05-17 | Parasoft Corporation | Modularizing a computer program for testing and debugging |
US6662357B1 (en) * | 1999-08-31 | 2003-12-09 | Accenture Llp | Managing information in an integrated development architecture framework |
US6331770B1 (en) * | 2000-04-12 | 2001-12-18 | Advantest Corp. | Application specific event based semiconductor test system |
CN1154045C (en) * | 2000-07-25 | 2004-06-16 | 华为技术有限公司 | Combined simulation system across platforms |
JP2002123562A (en) * | 2000-07-31 | 2002-04-26 | Hitachi Ltd | Method for generating tester structure data, method for structuring tester, and test circuit |
TW535082B (en) * | 2001-06-01 | 2003-06-01 | Chroma Ate Inc | Processing method for control and access of data with devices of automatic testing system |
US7111282B2 (en) * | 2001-06-12 | 2006-09-19 | Hewlett-Packard Development Company, L.P. | Instrumenting a software program and collecting data from the instrumented software program by type |
US7228326B2 (en) * | 2002-01-18 | 2007-06-05 | Bea Systems, Inc. | Systems and methods for application deployment |
US20040225459A1 (en) | 2003-02-14 | 2004-11-11 | Advantest Corporation | Method and structure to develop a test program for semiconductor integrated circuits |
US20040194064A1 (en) * | 2003-03-31 | 2004-09-30 | Ranjan Mungara Vijay | Generic test harness |
US7210087B2 (en) | 2004-05-22 | 2007-04-24 | Advantest America R&D Center, Inc. | Method and system for simulating a modular test system |
US7197416B2 (en) | 2004-05-22 | 2007-03-27 | Advantest America R&D Center, Inc. | Supporting calibration and diagnostics in an open architecture test system |
US7430486B2 (en) | 2004-05-22 | 2008-09-30 | Advantest America R&D Center, Inc. | Datalog support in a modular test system |
US20060130001A1 (en) * | 2004-11-30 | 2006-06-15 | International Business Machines Corporation | Apparatus and method for call stack profiling for a software application |
-
2005
- 2005-04-05 US US11/100,109 patent/US8082541B2/en not_active Expired - Fee Related
- 2005-12-01 TW TW094142344A patent/TWI383166B/en not_active IP Right Cessation
- 2005-12-08 WO PCT/JP2005/023004 patent/WO2006062252A1/en active Application Filing
- 2005-12-08 EP EP05816758A patent/EP1820036A1/en not_active Withdrawn
- 2005-12-08 JP JP2006515518A patent/JP4302736B2/en not_active Expired - Fee Related
- 2005-12-08 CN CN2005800418100A patent/CN101073016B/en not_active Expired - Fee Related
- 2005-12-08 KR KR1020077014690A patent/KR20070106692A/en not_active Application Discontinuation
-
2008
- 2008-08-07 JP JP2008203817A patent/JP2009064425A/en active Pending
Non-Patent Citations (3)
Title |
---|
PRAMANICK A ET AL: "Test programming environment in a modular, open architecture test system", TEST, 2004 INTERNATIONAL CONFERCE ON. CHARLOTTE, NC OCT. 26-28, 2004, PISCATAWAY, NJ, USA,IEEE, 26 October 2004 (2004-10-26), pages 413 - 422, XP010763855, ISBN: 0-7803-8580-2 * |
RAJSUMAN R: "An Overview of the Open Architecture Test System", ELECTRONIC DESIGN, TEST AND APPLICATIONS, 2004. DELTA 2004. SECOND IEEE INTERNATIONAL WORKSHOP ON PERTH, AUSTRALIA 28-30 JAN. 2004, PISCATAWAY, NJ, USA,IEEE, 28 January 2004 (2004-01-28), pages 341 - 341, XP010778701, ISBN: 0-7695-2081-2 * |
STORA M J: "Structured architecture for test systems (SATS) hardware interface standards", AUTOTESTCON '99. IEEE SYSTEMS READINESS TECHNOLOGY CONFERENCE, 1999. IEEE SAN ANTONIO, TX, USA 30 AUG.-2 SEPT. 1999, PISCATAWAY, NJ, USA,IEEE, US, 30 August 1999 (1999-08-30), pages 707 - 718, XP010356167, ISBN: 0-7803-5432-X * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2237125A1 (en) * | 2009-03-31 | 2010-10-06 | Siemens Aktiengesellschaft | Method of monitoring an analyser connected to a communications network in an industrial automation system and industrial automation system |
Also Published As
Publication number | Publication date |
---|---|
US8082541B2 (en) | 2011-12-20 |
TW200638054A (en) | 2006-11-01 |
KR20070106692A (en) | 2007-11-05 |
CN101073016A (en) | 2007-11-14 |
TWI383166B (en) | 2013-01-21 |
JP2008533542A (en) | 2008-08-21 |
US20060130041A1 (en) | 2006-06-15 |
JP2009064425A (en) | 2009-03-26 |
EP1820036A1 (en) | 2007-08-22 |
JP4302736B2 (en) | 2009-07-29 |
CN101073016B (en) | 2010-09-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8082541B2 (en) | Method and system for performing installation and configuration management of tester instrument modules | |
US7478385B2 (en) | Installing software using programmatic component dependency analysis | |
US7228541B2 (en) | Creation of application system installer | |
US5974567A (en) | Ghost partition | |
JP5362974B2 (en) | How to use virtualization software for shipping software products | |
US6922831B1 (en) | Method and system for providing software utilizing a restore medium and a network | |
US6598223B1 (en) | Method and system for installing and testing build-to-order components in a defined configuration computer system | |
US9037689B2 (en) | Provisioning of computer systems using virtual machines | |
US7330967B1 (en) | System and method for injecting drivers and setup information into pre-created images for image-based provisioning | |
US6550061B1 (en) | System and method for modifying configuration files in a secured operating system | |
US20050022087A1 (en) | Method and system for controlling interchangeable components in a modular test system | |
US7644264B1 (en) | Method and system for creating and deploying disk images | |
US20030055919A1 (en) | One-click deployment of data processing systems | |
US20080016396A1 (en) | Test emulator, test module emulator and record medium storing program therein | |
US20120216181A1 (en) | Automatic upgrade of virtual appliances | |
CZ25397A3 (en) | Computer system | |
US20080178143A1 (en) | System, Method and Computer Program Product for Developing, Configuring, Installing and Testing Software | |
WO2012069296A1 (en) | A method computer program and system for managing pre-requisite of a software product virtual image | |
WO2006013559A2 (en) | Storage area network boot server and method | |
US6021276A (en) | Method and apparatus for microcode downloading | |
US20060168564A1 (en) | Integrated chaining process for continuous software integration and validation | |
CA2016396C (en) | Initial program load (ipl) based on an object abstraction for a data processing system | |
US7277810B2 (en) | Method and apparatus for automating calibration of test instruments | |
Muehlbach et al. | Concurrent driver upgrade: Method to eliminate scheduled system outages for new function releases | |
Mueller et al. | Architecture drives test system standards |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 2006515518 Country of ref document: JP |
|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2005816758 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 200580041810.0 Country of ref document: CN |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020077014690 Country of ref document: KR |
|
WWP | Wipo information: published in national office |
Ref document number: 2005816758 Country of ref document: EP |