US20080033682A1 - System and method for performing processing in a testing system - Google Patents

System and method for performing processing in a testing system Download PDF

Info

Publication number
US20080033682A1
US20080033682A1 US11/827,094 US82709407A US2008033682A1 US 20080033682 A1 US20080033682 A1 US 20080033682A1 US 82709407 A US82709407 A US 82709407A US 2008033682 A1 US2008033682 A1 US 2008033682A1
Authority
US
United States
Prior art keywords
functions
test
another embodiment
hardware
location
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/827,094
Other languages
English (en)
Inventor
Barry Blancha
Leszek Lechowicz
Stephen Helm
Sean Adam
Jorge Camargo
Carlos Heil
Paulo Mendes
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shibasoku Co Ltd
Original Assignee
Asterion Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Asterion Inc filed Critical Asterion Inc
Priority to US11/827,094 priority Critical patent/US20080033682A1/en
Assigned to ASTERION, INC. reassignment ASTERION, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HEIL, CARLOS, ADAM, SEAN PATRICK, CAMARGO, JORGE, HELM, STEPHEN S, LECHOWICZ, LESZEK JANUSZ, BLANCHA, BARRY E
Publication of US20080033682A1 publication Critical patent/US20080033682A1/en
Assigned to SHIBASOKU CO., LTD. reassignment SHIBASOKU CO., LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ASTERION, INC.
Abandoned legal-status Critical Current

Links

Images

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/2832—Specific tests of electronic circuits not provided for elsewhere
    • G01R31/2834—Automated test systems [ATE]; using microprocessors or computers
    • 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
    • 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

Definitions

  • the invention relates generally to test systems, and more specifically, to test systems in the automatic test equipment (ATE) area.
  • ATE automatic test equipment
  • test equipment in the ATE area involves one or more computer systems.
  • a computer system that implements testing steps must be reliable and must generate test steps in a deterministic way. That is, the computer systems must be capable of producing consistent results.
  • One problem with such a computer is cost—design of a complete computing system suitable for use in testing (e.g., one that produces consistent results) requires not only the expensive hardware design and maintenance but also expensive software design involving operating system, user interface, drivers, tools, etc. More particularly, deterministic execution can be achieved using expensive computing hardware and software and/or distributed hardware within the tester, such as individual control processors within the instrument or other testing resource. As a result, computer systems suitable for ATE are prohibitively expensive for most companies to purchase and maintain.
  • ATE Automated test equipment
  • a typical ATE tester includes control hardware, sensors, and software that collects and analyzes the test results.
  • Such an ATE tester relies on particular test instruments to perform the testing and return results to the control software.
  • Conventional ATE testers and methodologies are widely considered to only be cost efficient for high-volume testing.
  • a key element in the design and construction of any new device or system is the ability to test the device or system for quality, functionality, and serviceability.
  • the first step in testing that new device is to determine if anyone already has a tester designed and working that may cover the new device. If one does not exist, the only option is to have a suitable tester built.
  • the current marketplace takes a long time to determine if a new tester should be built, let alone to begin actual construction of such a tester. Determining whether or not a new tester covering the new device would have wide demand, or any at all beyond the single use, ultimately determines whether the new tester will be made.
  • ATE systems are expensive due to the fact that they are specially-developed systems that have limited applications, among other reasons. Because they are highly specialized, they do not lend themselves to be mass-produced, or include mass-produced hardware and software components. In one aspect of the invention, it is appreciated that it would be beneficial to produce an ATE system using less expensive, more general-purpose components.
  • ATE systems are expensive due primarily to the tight coupling between software and hardware. More specifically, components of the ATE system such as the operating systems, test platforms, their associated applications, and underlying test hardware depend on each other, and when one of these components are changed, the ATE system may not function in the same manner prior to the change. In a deterministic system such as an ATE system, such a change may cause a test program to perform differently, producing non-deterministic test results.
  • test engineers are reluctant to implement new features in existing production test systems. For instance, if a new software-based test function is made available in an existing test system, introduction of that new software may break the operation of the current software. For instance, if a software driver is replaced by a later-version driver, the test system may not function in the same way, and test results may be affected. Similarly, if an improved hardware (e.g., a test instrument) is added to an existing ATE system, the hardware and/or software of the existing system may not function in the same way or at all. As a result, test engineers generally do not disturb existing test systems to implement new functionality, but rather would purchase new hardware and software for performing new test functions. This results in inefficient use of testing resources, and limited reuse of testing platforms. Further, the test hardware and software producer must rigorously test all possible permutations of components to prohibit problems from occurring in the field, thus increasing production costs and the overall cost of the test equipment.
  • test engineers may develop their own testing programs that use hardware and software of the ATE. Because their programs use the tightly-coupled hardware and software, their programs are also highly dependent on this tightly-coupled system, and any changes in the underlying system may cause their test programs to operate differently than expected. Because of this, test engineers are generally unwilling to consider new software and/or hardware changes to existing production test environments. Such test equipment may be used, for example, in manufacturing of electronic devices, and a failure of such equipment may impact manufacturing schedules.
  • a platform that permits components (e.g., hardware, software) to be changed without affecting the operation of other components.
  • components e.g., hardware, software
  • a test development platform may include test system software, software drivers used to communicate with various test instruments, and operating system software.
  • an architecture is provided that isolates the function of such components to reduce the amount of coupling between the components. In this way, the changing of one component does not affect the operation of other components.
  • test hardware e.g., a test instrument
  • a new version of the test hardware is available. This new version has a different interface than the failed test hardware, and it follows that the software and applications that access the new hardware need to be changed to adapt to the new interface.
  • this change results in increased maintenance costs for the test system, as all test programs and applications that used the old hardware will need to be changed and retested, as the communication between hardware and software was broken.
  • the user has no choice, as equipment manufacturers frequently change hardware and software, causing the overall system not to work.
  • testing applications and their associated software e.g., platform OS, drivers
  • hardware are tightly coupled.
  • an abstraction layer is provided that decouples the testing application from hardware.
  • a virtual instrument is provided that presents a common interface to a user. The interface, according to one embodiment, does not change when the underlying hardware changes, reducing the possibility that the application will not work when changes are made. Further, it follows that an application developed using the virtual instrument can be used among systems having different hardware types and/or versions, as hardware-specific implementations are, according to one embodiment, abstracted from the application.
  • a system architecture is provide that is modular, linked by interfaces.
  • modules are linked by add-only interfaces, wherein functionality can be only added to particular interfaces, thereby ensuring that existing code and test programs are not “broken.”
  • such interfaces are abstracted to only those functions that are specifically necessary.
  • a flexible tester that can be fabricated in a shorter time, that is cost efficient, and adaptable to cover new devices will meet the needs of the marketplace.
  • conventional architectures still result in hardware specific code being incorporated with system code making them dependant on specific hardware and rendering them useful in only a narrow range of applications.
  • the interdependence and intermingling of function and software limits conventional ATE testers.
  • any change (additions or subtractions of hardware, and in some cases replacement of identical parts) can result in a tester that does not function properly. Restoring the changed ATE tester to proper function requires additional expenses and increases time to market for the devices to be tested.
  • ATE testers The inflexibility of conventional ATE testers increases the costs associated with developing and maintaining testers. With conventional methods, development of new testers generally requires construction from scratch and fails to leverage what is already in place.
  • One aspect of the present invention describes an instrument developer platform defining a set of architecture standards that enable the timely development of new ATE testers that can test a virtually unlimited range of devices. This architecture also allows for the modification of existing testers to include new instrumentation without requiring changes to existing test functionality and its related software. This test system architecture is able to incorporate new instrumentation into an existing tester, and thus leverage what is in place. This is accomplished through the abstraction of sets of functionality in an ATE tester.
  • an instrument incorporated into a particular tester is abstracted into a functional module.
  • This abstracted module manages the functions of the particular instrument while remaining independent of the rest of the ATE tester.
  • interfaces defined at a platform level allow for independence of the test platform itself.
  • the module is called by other independent abstraction layers.
  • the module independent of the abstraction layer(s) which called it, manages the functions of the instrument and the module returns the results to the that abstraction layer.
  • the tester interacts with the module only through other independent abstraction layers, the module and its related instrument is permitted to be “plugged-in” to any tester that employs the same architecture.
  • the module and the related instrument can be removed from one tester and by installing the same module and instrument on another tester (of the same architecture), the functionality of the second tester is enhanced without impacting the existing functions of the second tester.
  • the first tester from which a module and instrument were extracted, will continue to function with the remaining instruments available to it. Adhering to the architecture standards enables flexibility on existing testers, cost efficiency, and greater speed to completion of new testers.
  • each level of functionality of an ATE tester is abstracted, enabling sets of functions and functionalities to be separated in different layers encompassing the functions of an ATE tester.
  • users interact with test programs, which bundle visualizations and graphically display results and options from tests performed, or to be performed, on a particular device. For instance, a single test program or multiple programs may be employed by the user to test any particular device or devices.
  • the abstraction of the functions and functionality provided by test program(s) forms the highest layer of the ATE tester architecture.
  • a system in which virtual instruments can be created and managed.
  • the virtual instrument being modeled includes behavior that based on the functionality that is desired by the user, rather than hardware-specific implementations. For instance, if a particular function is not natively performed in a software driver, that functionality can be performed in software associated with the virtual instrument. In this way, capabilities of test hardware and their associated drivers may be extended in a standard way. Further, according to another embodiment, because virtual instruments are created from the user perspective, applications are more easily created.
  • testers and their applications can be created more quickly, as testers are not tied to their hardware.
  • hardware associated with a tester can be improved more easily, as software is not so rigidly tied to hardware, and therefore, hardware can be added/changed without affecting software (software will more easily work with hardware). It is appreciated that such a flexible platform for creating and maintaining software and hardware is beneficial to the developer and maintainer of software, and the amount of cost and effort for creating and maintaining testing programs is reduced.
  • a method for providing software functions is provided that permits compatibility across software and hardware versions.
  • functions of a virtual instrument that refer to hardware functions are unchanged from version to version. More particularly, as functions are added to the virtual instrument, old functions are maintained, and functionality is added to a predetermined memory structure. Functionality to software modules are added without changing references of preexisting functions in memory. Because function references are unchanged, additional functionality, when added to the memory structure does not “break” existing connections. Thus, when a test program is created, the program's functionality is frozen in time, as the functions that the test program accesses remain unchanged going forward, unless the user decides to change the test program. In this way, development and maintenance costs for creating and maintaining test programs is significantly reduced.
  • a virtual function table (e.g., in the C++ programming language, the well-known virtual method table (“vtable”)) is maintained for a virtual instrument.
  • vtable virtual method table
  • a base set of functionality is included having a defined location in the vtable.
  • additional functions are added to the vtable, while maintaining the same location in the vtable for the base set of functionality. In this way, functions and their connections to other software are maintained without breaking existing programs when additional functions are added.
  • a virtual multisite instrument that facilitates management of multiple testing sites.
  • a site is managed as a singular entity in that if a particular testing site is configured, a test program is developed for the particular site, specific to the particular testing hardware used. If multiple sites are needed to perform additional testing (e.g., to satisfy an increased testing capacity), then additional test hardware configurations are purchased, and the test program is matriculated to the additional sites.
  • test programs can be managed independent of test hardware, and the abstraction layer may be capable of managing the administration of a test program to multiple sites via the abstraction layer.
  • the virtual instrument may have capability to map to multiple instrument sites. In this way, the time needed to maintain and administer test programs to multiple sites is reduced.
  • test programs software is used by different types of users—some users develop test applications, and others use the developed applications for the administration and management of test processes.
  • these separate types of users may need to use a specific user interface (UI), depending on what functions are performed.
  • UI user interface
  • multiple types of testers have different user interfaces, forcing the user to understand the specific type of interface necessary to run the equipment.
  • the application and drivers are tightly coupled, and the user interfaces are tied to the system software.
  • a standard user interface may be used to access multiple tester types, reducing the amount of training necessary for the user.
  • a user-specific interface is provided that allows the user to perform testing functions related to their role.
  • a testing architecture that permits a user to perform testing functions from any location.
  • the user interface is accessed through a browser program, and a user may perform testing functions from any location coupled to a testing system through a communications network.
  • the UI is normally tied to the machine, however, if the UI is made available over a network, the user can perform testing from another location.
  • a system comprises a test program, an platform adapted to generate a plurality of function calls in response to requests from the test program, an abstraction layer that is adapted to map the plurality of function calls into instructions to be executed on test hardware.
  • the abstraction layer further comprises a virtual instrument (“VI”) interface to the platform.
  • the abstraction layer further comprises a virtual multisite (“VMI”) interface to the platform.
  • the abstraction layer further comprises a system physical instrument (“SystemPI”) interface to the platform.
  • SystemPI system physical instrument
  • the abstraction layer further comprises a physical instrument (“PI”) interface to the platform.
  • the abstraction layer further includes a virtual instrument (“VI”) to physical instrument (“PI”) interface.
  • the abstraction layer further includes a system physical instrument (“SystemPI”) to virtual instrument (“VI”) interface.
  • the abstraction layer further includes a system physical instrument (“SystemPI”) to physical instrument (“PI”) interface.
  • the abstraction layer further includes a test program to virtual instrument (“VI”) interface.
  • the abstraction layer further includes a test program to physical instrument (“PI”) interface.
  • the abstraction layer further includes a platform to virtual instrument (“VI”) interface.
  • the abstraction layer further includes a platform to physical instrument (“PI”) interface.
  • the abstraction layer further includes a platform to virtual multisite instrument (“VMI”) interface.
  • the abstraction layer further comprises an interface generation engine.
  • the interface generation engine includes a graphical user interface adapted to guide a user through generation of an interface.
  • the interface generation engine generates an interface to manage communication between components of the system.
  • the interface generation engine generates an interface to manage communication between components of the abstraction layer.
  • the interface generation engine generates an interface to manage communication between the platform and the abstraction layer.
  • managing communication between the platform and the abstraction layer includes mapping the plurality of function calls to instructions to be executed on test hardware.
  • mapping the plurality of function calls includes mapping the plurality of function calls to a virtual instrument (“VI”) module.
  • mapping the plurality of function calls includes mapping the plurality of function calls to a system physical instrument (“System PI”) module.
  • mapping the plurality of function calls includes mapping the plurality of function calls to a physical instrument (“PI”) module.
  • mapping the plurality of function calls includes mapping a base class of physical instrument function calls to a physical instrument (“PI”) module.
  • mapping the plurality of function calls includes mapping a base class of physical instrument function calls to a physical instrument (“PI”) module.
  • the abstraction layer further comprises a rules checking engine.
  • the rules checking engine is adapted to verify the mapping of function calls to instructions on the test hardware.
  • the rules checking engine verifies the mapping by simulating a request for the function call.
  • the rules checking engine verifies the mapping by accepting a response as a result of the simulated function call in an expected format.
  • the rules checking engine returns a code to the operating platform indicating that the function call was mapped properly.
  • the rules checking engine identifies an improper mapping by accepting a return code in response to the simulated function call that is not in the expected format.
  • the system further comprises an interface between the test program and the platform.
  • the test program provides a graphical user interface to a user.
  • the test program enables a user to define tests to be executed upon a device.
  • the test program enables a user to define tests to be executed upon a device to occur at any time.
  • the abstraction layer further comprises an physical instrument abstraction layer representing the functionality of hardware resources of the test system.
  • the physical instrument abstraction layer includes a physical instrument module that maps to a hardware resource.
  • the PI module causes execution of instructions on a hardware resource in response to requests.
  • a hardware resource includes at least one function available on the test hardware.
  • the hardware resource is adapted to cause the generation of a synchronization signal.
  • the hardware resource is adapted to causes a device state query.
  • the PI module includes a function call that will cause a device to power on and/or initialize in dependence upon a device starting state.
  • the physical instrument module includes a base class of PI function calls.
  • the base class of PI function calls includes the power on and/or initialize function.
  • the abstraction layer further comprises a virtual instrument abstraction layer that represents a virtualization of hardware functions that may be performed on the test system.
  • the virtual instrument abstraction layer includes a virtual instrument (“VI”) module, to which at least one hardware resource is mapped.
  • the VI module is adapted to cause the execution of instructions on a hardware resource in response to requests.
  • the mapping to at least one resource is mapped through at least one PI module for each of the at least one hardware resource.
  • the VI module is mapped to a plurality of PI modules to render a virtual representation of a set of predefined hardware resources employed to test a particular device.
  • the VI module is adapted to be modified to include an additional PI module, expanding the set of hardware resources available to test a device through the VI module.
  • the VI module is adapted to include a base class of functions that map to test hardware resources necessary for any ATE tester.
  • the abstraction layer further comprises a system abstraction layer adapted to manage requests to hardware resources.
  • the system abstraction layer is further adapted to map requests from a physical instrument layer so that hardware resources perform their functions in response to requests.
  • the system abstraction layer is further adapted to define a base set of system function calls available to other components of the abstraction layer.
  • system layer further comprises a SystemPI module adapted to define a base set of system function calls that cause operations to be performed any the other components of the abstraction layer.
  • system abstraction layer is further adapted to perform queries on components of the abstraction layer.
  • the system abstraction layer includes a system physical instrument module.
  • the platform layer includes an “off the shelf” operating system.
  • the “off the shelf” operating system is enhanced to perform deterministically.
  • the “off the shelf” operating system is Windows XP, and it is enhanced using the Tenasys INtime operating system to operate deterministically.
  • an automated test equipment system comprising a platform abstraction layer adapted to manage the operation of abstraction layers of the automated test equipment system, a physical instrument (“PI”) abstraction layer adapted to map PI function calls to hardware so that the hardware performs a function in response to a PI function call, a virtual instrument (“VI”) abstraction layer adapted to map to the PI abstraction layer so that the VI abstraction layer represents a virtualization of hardware functions that may be performed, a system abstraction layer adapted to map system function calls to enable the hardware to perform functions in response to PI function calls, and a test program abstraction layer adapted to interact with the virtual instrument layer to initiate functions performed on hardware.
  • PI physical instrument
  • VI virtual instrument
  • the system abstraction layer is further abstracted into a system physical instrument (“SystemPI”) module that receives requests from the PI abstraction layer and causes hardware to perform its function in response.
  • SystemPI module is further adapted to aggregate information reported by the other abstraction layers of the automated test equipment system.
  • the information aggregated includes success or failure of function calls made in the other abstraction layers of the automated test equipment system.
  • the information aggregated includes reporting by operations in the other abstraction layers of the automated test equipment system.
  • SystemPI module is further adapted to accept queries on the information aggregated.
  • SystemPI module is further adapted to report on the information aggregated.
  • the test program abstraction layer includes a test program adapted to present a graphical user interface to a user.
  • the test program layer is further adapted to permit a user to interact with the virtual instrument layer.
  • the test program layer is further adapted to permit a user to define tests to be performed on a device.
  • the test program is further adapted to graphically render the results of performed tests.
  • the test program layer is further adapted to permit a user to define tests to be performed on a device, wherein the tests to be performed occur at a scheduled time.
  • tests to be performed can occur on any user defined schedule.
  • the virtual instrument abstraction layer includes a VI module, wherein the VI module includes a mapping to at least one hardware resource.
  • the VI module is adapted to cause the at least one hardware resource to perform its function in response to requests.
  • the VI module causes the at least one hardware resource to perform its function in response to a request from the test program abstraction layer.
  • the mapping to the at least one hardware resource is mapped through the PI instrument layer.
  • the mapping to the at least one hardware resource is mapped through a PI module.
  • the VI module is mapped to a plurality of PI modules so that the VI module renders a virtual representation of a plurality of hardware resources employed to test a device.
  • the mapping between the VI Module and the PI module is managed by an interface.
  • the interface is a graphical user interface.
  • the interface manages communication between the VI Module and the PI module in a predetermined format.
  • the VI module is adapted to be modified to include a mapping to an additional PI module.
  • the VI module is adapted to include a base class of functions that map to test hardware resources necessary for any ATE tester.
  • the physical instrument abstraction layer includes a PI module that contains the implementation details of a hardware resource.
  • the physical instrument abstraction layer includes a PI module that contains the implementation details of each hardware resource.
  • the physical instrument abstraction layer is adapted incorporate the implementation details of a new hardware resource.
  • the new hardware resource is mapped to by a new PI module.
  • the PI module causes execution of the hardware resource's functionality in response to requests.
  • the request comes from a VI module.
  • the hardware resource's functionality includes a synchronization signal.
  • the physical instrument module includes a function call that will cause a hardware resource to power on and/or initialize.
  • the function call includes the PowerOnInitialize function.
  • the PI abstraction layer includes a base class of PI function calls.
  • the base class of PI function calls includes the function call adapted to cause a hardware resource to power on and/or initialize.
  • the function call adapted to cause a hardware resource to power on and/or initialize includes the PowerOnInitialize function.
  • the platform abstraction layer includes an “off the shelf” operating system.
  • the “off the shelf” operating system is enhanced to perform deterministically.
  • the “off the shelf” operating system is Windows XP.
  • the operating system is enhanced to perform deterministically using real-time extensions.
  • the real-time extensions are provided through the “Tenasys INtime” operating system.
  • the platform abstraction layer operates deterministically.
  • the system further comprises an interface abstraction layer adapted to manage the communication between the abstraction layers.
  • the interface abstraction layer is further adapted to insure standardized communication between the abstraction layers.
  • the interface abstraction layer includes a interface between the platform abstraction layer and the VI abstraction layer.
  • the interface abstraction layer includes a interface between the platform abstraction layer and the system abstraction layer.
  • the interface abstraction layer includes a interface between the platform abstraction layer and the physical instrument abstraction layer. According to another embodiment of the invention, the interface abstraction layer includes a interface between a VI module and a PI module. According to another embodiment of the invention, the interface abstraction layer includes an interface between a SystemPI module and a VI module. According to another embodiment of the invention, the interface abstraction layer includes an interface between a SystemPI module and a PI module. According to another embodiment of the invention, the interface abstraction layer includes a interface between the platform abstraction layer and the VI abstraction layer.
  • the system further comprises a module generation engine adapted to guide a user through the creation of one of a PI module and a VI module so that the automated test system is capable incorporating new test hardware resources.
  • the system further comprise an interface generation engine adapted to guide a user through the creation of an interface, wherein the interface will manage communication between modules by standardizing the format of communication without consideration of the hardware, software or platform being employed on the automated test system.
  • the system further comprises a rule checking engine adapted to verify the test functionality of a generated module and its generated interface.
  • the system further comprises an installation module adapted to permit a user to install the generated module so that the test program could direct requests to the generated module and have test functions performed.
  • the system further comprises an installation module adapted to permit a user to install the generated interface so that the test program may direct requests to the test hardware resources mapped to by the generated module and have test functions performed.
  • a system for performing a testing process is provided.
  • the system comprises a test program that, when executed, performs a procedure on one or more test instruments, the one or more test instruments having respective one or more driver programs, and a virtual instrument entity adapted to execute the procedure on the one or more test instruments, wherein the virtual instrument entity accesses the one or more test instruments through the respective one or more driver programs.
  • the virtual instrument entity includes one or more functions.
  • the test program is adapted to access the one or more test instruments by accessing the one or more functions of the virtual instrument.
  • the test program is programmed to access the one or more instruments only through the virtual instrument.
  • the test program is programmed to access a system physical interface to gain access to tester resources.
  • the virtual instrument entity isolates the test program from programming interfaces specific to the one or more test hardware.
  • the virtual instrument includes a virtual instrument programming interface.
  • a change in the one or more test instruments does not produce a corresponding change in the virtual instrument programming interface.
  • a change in the virtual instrument entity does not produce a corresponding change in the one or more functions.
  • a change in a physical tester resource does not produce a corresponding change in the one or more functions.
  • a change in a testing development platform does not require a change in the test platform.
  • the one or more functions are loaded in a memory structure of a computer system.
  • the change in the virtual instrument entity does not produce a corresponding change in the memory structure of the computer system.
  • the one or more functions are located in a first location in the memory structure of the computer system.
  • the change in the virtual instrument entity includes adding one or more additional functions.
  • the change in the virtual instrument entity includes modifying at least one of the one or more functions.
  • the one or more additional functions are added in a second location following the first location in the memory structure of the computer system.
  • the addition of the one or more additional functions does not change the location of the one or more functions in the first location in the memory structure of the computer system.
  • the memory structure of the computer system further comprises a vtable.
  • the addition of the one or more additional functions does not change a location of the one or more functions in the vtable.
  • the change in the virtual instrument entity includes adding at least one modified function.
  • the at least one modified function is modified from the at least one of the one or more functions.
  • the at least one modified function is added in a second location following the first location in the memory structure of the computer system.
  • the addition of the at least one modified function does not change the location of the one or more functions in the first location in the memory structure of the computer system.
  • the memory structure of the computer system further comprises a vtable.
  • the addition of the at least one modified function does not change a location of the one or more functions in the vtable.
  • the one or more functions is included in a base programming class of functions, and the base programming class is inherited from an extended class of functions including the one or more additional functions.
  • the one or more functions is included in a base programming class of functions, and the base programming class is inherited from an extended class of functions including the at least one modified function.
  • the computer system includes a general-purpose computer system.
  • the one or more test instruments are coupled to one or more devices under test.
  • at least one of the one or more test instruments is programmed by the test program to apply a test signal to at least one of the one or more devices under test.
  • a system for performing a testing process comprises one or more test instruments, each having respective one or more driver programs and wherein at least one of the driver programs includes one or more functions, a test program that, when executed, performs a procedure on the one or more test instruments, the test program accessing the one or more test instruments through the one or more driver programs, and a memory structure, wherein the one or more functions of the at least one of the driver programs are contained within a fixed location with the memory structure.
  • the memory structure is included in a memory of a computer system, and wherein the one or more functions are loaded in the memory of the computer system.
  • a change in the at least one of the driver programs does not produce a corresponding change in the memory structure.
  • the one or more functions are located in a first location in the memory structure.
  • the change in the at least one of the driver programs includes adding one or more additional functions.
  • the change in the at least one of the driver programs includes modifying at least one of the one or more functions.
  • the one or more additional functions are added in a second location following the first location in the memory structure.
  • the addition of the one or more additional functions does not change the location of the one or more functions in the first location in the memory structure.
  • the memory structure further comprises a vtable.
  • the addition of the one or more additional functions does not change a location of the one or more functions in the vtable.
  • the change in the virtual instrument entity includes adding at least one modified function.
  • a change in a platform entity includes adding at least one modified function.
  • a change in a physical instrument driver includes adding at least one modified function.
  • the at least one modified function is modified from the at least one of the one or more functions.
  • the at least one modified function is added in a second location following the first location in the memory structure. According to another embodiment of the invention, the addition of the at least one modified function does not change the location of the one or more functions in the first location in the memory structure. According to another embodiment of the invention, the memory structure further comprises a vtable. According to another embodiment of the invention, the addition of the at least one modified function does not change a location of the one or more functions in the vtable. According to another embodiment of the invention, the one or more functions is included in a base programming class of functions, and the base programming class is inherited from an extended class of functions including the one or more additional functions.
  • the one or more functions is included in a base programming class of functions, and the base programming class is inherited from an extended class of functions including the at least one modified function.
  • the computer system includes a general-purpose computer system.
  • the one or more test instruments are coupled to one or more devices under test.
  • at least one of the one or more test instruments is programmed by the test program to apply a test signal to at least one of the one or more devices under test.
  • the system is part of an automated test system.
  • the system further comprises a virtual instrument entity adapted to execute the procedure on the one or more test instruments, wherein the virtual instrument entity accesses the one or more test instruments through the respective one or more driver programs.
  • the virtual instrument entity includes one or more functions.
  • the test program is adapted to access the one or more test instruments by accessing the one or more functions of the virtual instrument.
  • the test program is programmed to access the one or more instruments only through the virtual instrument.
  • the virtual instrument entity isolates the test program from programming interfaces specific to the one or more test hardware.
  • the virtual instrument includes a virtual instrument programming interface.
  • a change in the one or more test instruments does not produce a corresponding change in the virtual instrument programming interface.
  • a change in the virtual instrument entity does not produce a corresponding change in the one or more functions.
  • the one or more functions are loaded in a memory structure of a computer system.
  • the change in the virtual instrument entity does not produce a corresponding change in the memory structure of the computer system.
  • the one or more functions are located in a first location in the memory structure of the computer system.
  • the change in the virtual instrument entity includes adding one or more additional functions.
  • the change in the virtual instrument entity includes modifying at least one of the one or more functions.
  • the one or more additional functions are added in a second location following the first location in the memory structure of the computer system.
  • the addition of the one or more additional functions does not change the location of the one or more functions in the first location in the memory structure of the computer system.
  • the memory structure of the computer system further comprises a vtable.
  • the addition of the one or more additional functions does not change a location of the one or more functions in the vtable.
  • the change in the virtual instrument entity includes adding at least one modified function.
  • the at least one modified function is modified from the at least one of the one or more functions.
  • the at least one modified function is added in a second location following the first location in the memory structure of the computer system.
  • the addition of the at least one modified function does not change the location of the one or more functions in the first location in the memory structure of the computer system.
  • the memory structure of the computer system further comprises a vtable.
  • the addition of the at least one modified function does not change a location of the one or more functions in the vtable.
  • the change in the virtual instrument entity includes adding one or more additional functions.
  • the one or more functions is included in a base programming class of functions, and the base programming class is inherited from an extended class of functions including the one or more additional functions.
  • the one or more functions is included in a base programming class of functions, and the base programming class is inherited from an extended class of functions including the at least one modified function.
  • the computer system includes a general-purpose computer system.
  • a system for performing a testing process comprises a test program that, when executed, performs a procedure on a plurality of test instruments, the one or more test instruments having respective one or more driver programs, and a virtual multisite instrument entity adapted to execute the procedure on the plurality of test instruments, wherein the virtual instrument entity accesses the plurality of test instruments through the respective one or more driver programs, wherein the virtual multisite instrument entity is adapted to execute the procedure on the plurality of test instruments transparently to the test program.
  • the virtual multisite instrument includes functionality that controls a plurality of instrument sites.
  • the virtual multisite instrument entity includes one or more functions.
  • the test program is adapted to access the plurality of instruments by accessing the one or more functions of the virtual instrument.
  • the test program is programmed to access the plurality of instruments only through the virtual instrument.
  • the virtual multisite instrument isolates the test program from programming interfaces specific to the plurality of instruments.
  • the virtual multisite instrument includes a virtual multisite instrument programming interface.
  • a change in at least one of the plurality of test instruments does not produce a corresponding change in the virtual multisite instrument programming interface.
  • a change in the virtual multisite instrument entity does not produce a corresponding change in the one or more functions.
  • the one or more functions are loaded in a memory structure of a computer system.
  • the change in the virtual multisite instrument entity does not produce a corresponding change in the memory structure of the computer system.
  • the virtual multisite instrument entity is adapted to execute the procedure substantially in parallel on the plurality of test instruments.
  • a system for performing a testing process comprises a test system, and at least one client computer coupled to the test system by a communication network, wherein a user operating the client computer is capable of executing a plurality of testing functions on the test system.
  • the system further comprises a test program that, when executed, performs a procedure on one or more test instruments, the one or more test instruments having respective one or more driver programs.
  • the system further comprises a process that receives one or more requests from client computers through the communication network.
  • the at least one client computer includes a user interface component for accessing the test system.
  • the user interface component is operated using a browser program executing on the at least one client computer.
  • the test system further comprises a virtual multisite instrument entity adapted to execute the procedure on the plurality of test instruments, wherein the virtual instrument entity accesses the plurality of test instruments through the respective one or more driver programs, wherein the virtual multisite instrument entity is adapted to execute the procedure on the plurality of test instruments transparently to the test program.
  • the test system further comprises a virtual instrument entity adapted to execute the procedure on the one or more test instruments, wherein the virtual instrument entity accesses the one or more test instruments through the respective one or more driver programs.
  • the user interface component is configured based on the user operating the client computer.
  • the test system is adapted to store a plurality of user interfaces, and is adapted to provide at least one user interface to the user based on a user interface configuration associated with the user.
  • the virtual instrument entity includes one or more functions.
  • the test program is adapted to access the one or more test instruments by accessing the one or more functions of the virtual instrument.
  • the test program is programmed to access the one or more instruments only through the virtual instrument.
  • the virtual instrument entity isolates the test program from programming interfaces specific to the one or more test hardware.
  • the virtual instrument includes a virtual instrument programming interface.
  • FIG. 1 shows a block diagram of an example conventional test system architecture
  • FIG. 2 shows a block diagram of another example conventional test system architecture
  • FIG. 3 shows a block diagram of a test system architecture according to one embodiment of the present invention
  • FIG. 4 is a block diagram of a test system architecture according to one embodiment of the present invention.
  • FIG. 5 is a block diagram of a test system architecture according to another embodiment of the present invention.
  • FIG. 6A is a block diagram of a test system architecture according to another embodiment of the present invention.
  • FIG. 6B is a block diagram of a test system architecture according to another embodiment of the present invention.
  • FIG. 6C is a block diagram of a test system architecture according to another embodiment of the present invention.
  • FIG. 6D is a block diagram of a test system architecture according to another embodiment of the present invention.
  • FIG. 7 is a block diagram of a test system platform according to one embodiment of the present invention.
  • FIG. 8 is a block diagram of a memory structure which may be used to implement aspects of the present invention.
  • FIG. 9A is a block diagram of a test system architecture according to one embodiment of the present invention.
  • FIG. 9B is a block diagram of a memory structure according to one embodiment of the present invention.
  • FIG. 9C is a block diagram of a memory structure according to another embodiment of the present invention.
  • FIG. 10 is a block diagram of a memory structure according to another embodiment of the present invention.
  • FIG. 11 is a block diagram of a test system architecture according to another embodiment of the present invention.
  • FIG. 12 is a block diagram of a general-purpose computer system with which various aspects of the present invention may be practiced
  • FIG. 13 is a block diagram of a test system test system architecture according to another embodiment of the present invention.
  • FIG. 14 is a diagram of an example test system process according to one embodiment of the present invention.
  • FIG. 15 is a block diagram of an example alarm processing function according to one embodiment of the present invention.
  • FIG. 16 is a flow diagram of an example power initialize function according to one embodiment of the present invention.
  • a system and method is provided for performing processing in a testing system such as an ATE system.
  • ATE system it is appreciated that conventional ATE systems are expensive due primarily to the tight coupling between software and hardware.
  • an improved method for performing processing in an ATE system is provided which reduces the overall cost of software.
  • general-purpose computer systems, processors, and/or software to reduce the cost of ownership and maintenance of such systems.
  • various aspects of the invention may be embodied using off-the-shelf hardware and software (e.g., a general-purpose computer system, a commodity operating system (e.g., Windows NT), etc.).
  • the cost of developing an ATE system may be a fraction of the cost of a specially-designed system using specifically-developed hardware and software.
  • any method for reducing the overall cost of developing such a system is beneficial.
  • FIG. 1 shows a block diagram of an example conventional test system architecture.
  • a conventional test system 100 generally includes one or more portions of test system software 101 along with any corresponding test system hardware 102 .
  • the test system software may include, for example, an operating system, which is generally a special-purpose operating system, one or more test system software drivers (e.g., 104 A- 104 B), and any testing applications developed for testing one or more devices under test 106 A- 106 B.
  • test system software 101 includes software drivers (e.g., 104 A) that are implementation-specific to the instrument (e.g., instrument 105 A) to which the driver communicates. It follows that the test system software 101 which communicates with one or more software drivers is specifically-programmed to communicate with test system hardware 102 through such drivers (e.g., drivers 104 A- 104 B).
  • test system software 101 such as, for instance, an operating system, test applications, or other software entities are written specifically to communicate through such drivers, that a corresponding change in the driver or hardware forces a change in the test system software 101 . Because of this coupling, the test system software 101 must be recertified to work with software drivers and/or instruments which have been changed or added to test system 100 . Further, a user 103 that writes test programs to work on test system 100 must perform additional effort to ensure that their test programs work with the changed environment.
  • FIG. 2 shows a block diagram of another example conventional test system architecture that describes in more detail some of the problems in the conventional test programming environment.
  • a test system 100 may include test system software 101 that comprises one or more test applications 201 A- 201 Z, each of which may have different versions having varying capabilities to work with one or more types of software and hardware.
  • there may be on a particular test system one or more drivers e.g., driver A 202 A and driver B 203 A
  • each of which may have one or more versions associated with it (e.g., driver A versions 202 A- 202 Z and driver B versions 203 A- 203 Z).
  • Further complication includes the test system operating system which itself may have one or more versions 204 A- 204 Z and which may be configured to work with any number of other software entities including drivers, applications, or other entities.
  • test system hardware 102 may include one or more test hardware entities (e.g., test hardware A 205 A, test hardware B 206 A) that may include one or more versions (e.g., test hardware A versions 205 A- 205 Z, test hardware B versions 206 A- 206 Z) that may have various interfaces and features.
  • test hardware entities e.g., test hardware A 205 A, test hardware B 206 A
  • versions e.g., test hardware A versions 205 A- 205 Z, test hardware B versions 206 A- 206 Z
  • a modification in any one of these entities may cause communication or function to perform differently and cause the overall test system 100 to fail. In an ATE environment which requires that test programs be performed in a deterministic way, such a non-deterministic operation would not be desired.
  • a virtual instrument that isolates software applications from the underlying drivers and hardware (e.g., a test instrument) such that a change in the driver or instrument does not affect the function of higher layer software such as an operating system, a testing application or other software entity.
  • FIG. 3 shows a block diagram of a test system architecture according to one embodiment of the present invention that provides isolation between entities of a test system.
  • An architecture 300 is provided wherein a software application 301 , which may include, for example, a test system application, an operating system, or any other type of software entity which is isolated from details of the physical instrument driver 303 and physical instrument 304 by a virtual instrument 302 .
  • Virtual instrument 302 may become, for example, an abstraction layer that isolates the software application 301 and physical instrument driver 303 layers.
  • Virtual instrument 302 may include, for example, code that performs a mapping between an abstract virtual instrument interface (not shown) and functions and data existing within the physical instrument driver 303 .
  • the interface presented by the virtual instrument is a standard instrument interface that is independent of the underlying hardware.
  • the virtual instrument interface is written from the perspective of functionality that a user would generally like to perform (for instance, generate a wave form for a device under test (DUT)).
  • DUT device under test
  • the user is not concerned with specifics of the hardware, and they are only concerned with providing predictable stimuli and receiving predictable results. Therefore, an interface is provided that presents to the user hardware-independent functional interfaces that can be accessed by users' test programs in a standard way. Because of such a standardization of a virtual instrument, underlying physical instrument drivers and their corresponding instruments may be added or substituted without affecting the operation of upper layer software applications 301 .
  • Various aspects of the present invention may be implemented as a part of an overall system architecture that permits developers, equipment manufacturers, test equipment companies and other types of users to program test programs used for testing various devices under test (DUTs).
  • DUTs devices under test
  • test programs 405 A- 405 Z are developed by one or more users to operate on platform software 401 .
  • test programs 405 A- 405 Z may be programmed to access test hardware through a virtual multisite instrument layer 404 A- 404 Z.
  • virtual multi-site instruments are discussed in more detail below, but in general are similar to virtual instruments above in function in that they provide a virtual interface to one or more hardware devices.
  • Such interfaces may be capable of presenting a hardware-independent interface for performing test functions in an ATE system.
  • the software interface to a physical piece of hardware is implemented to what is referred to herein as a “Physical Instrument” (PI) module.
  • PI Physical Instrument
  • Each piece of instrumentation hardware is accompanied by an associated PI module that implements the basic functionality provided by the hardware.
  • the user's test program (TP) does not interact directly with a PI layer ( 403 A- 403 Z) entities (e.g., a PI module). Rather, from the user test program's point of view, interaction with the test instrumentation is made through what is referred to herein as a “Virtual Multisite Instrument” (VMI) discussed further below.
  • VMIs implement their functionality by using one or more PIs, which in turn, access one or more instruments.
  • VMI Virtual Multisite Instrument
  • test programs can be managed independent of test hardware, and the abstraction layer may be capable of managing the administration of a test program to multiple sites via the abstraction layer.
  • the virtual instrument may have capability to map to multiple instrument sites. In this way, the time needed to maintain and administer test programs to multiple sites is reduced.
  • PIs can access test system resources through a specially-defined PI referred to herein as the “System PI.”
  • the System PI layer e.g., layers 402 A- 402 Z
  • the System PI may provide a communication interface to other instruments in a test system.
  • PIs may be implemented, for example, in a general purpose computer system as a software library function (e.g., a Dynamic Linked Library (DLL) as well-known in the Windows NT operating system). Appropriate PI modules may be loaded as needed, depending on the hardware present in the test system.
  • a software library function e.g., a Dynamic Linked Library (DLL) as well-known in the Windows NT operating system.
  • DLL Dynamic Linked Library
  • each PI is uniquely identified by a unique identifier.
  • the unique identifier may be unique across the test system to uniquely identify a particular PI implementation. Such identification may be useful, for example, for communicating with PIs by other entities within the test system.
  • the system layer (e.g., as implemented by a system driver) interfaces that allow for VMI and PI to be built upon the system layer.
  • the VMI layer provides an abstraction layer from the hardware, which is encapsulated by the PI and System Driver software.
  • the system layer can also expose functions to the test program for system specific resources (e.g., a calibration meter).
  • the Test Program exposes any VMI functions to the user—as a Virtual Instrument, the test program provides these functions in a manner which captures what the user wants the test solution to look like.
  • the interfaces are guided by rules: add only, existing functions do not change in execution functionality or performance. Also, in one implementation each module performs version checking on module being interacted with so that adequate performance between modules is ensured.
  • Such rules may allow, for example, for complete forward-backward compatibility of the modules. That is, each module can be versioned independently and all versions can work interchangeably. This permits, for example, test programs designed with a given version of VMIs can use any PI and System Driver (of the same type) version equal-to or greater-than the versions used to when the test program was created and compiled.
  • architecture 400 may include platform software 401 .
  • the functionality provided by a conventional computer operating system is abstracted to be part of the platform software layer.
  • the platform layer is abstracted so that almost any operating system can be used with an ATE tester, such as general-purpose operating systems as discussed further below.
  • the platform software layer 401 provides the basic functionality required by all the various components of the ATE tester to operate and communicate.
  • the Windows XP or Windows Vista operating systems may be used as the base operating system, which may govern basic functions required by the various ATE tester components.
  • other operating systems may be used.
  • FIG. 5 shows a more detailed example of a test system architecture 400 according to one embodiment of the present invention.
  • an architecture 500 may include a platform software entity 501 that performs basic functions of the test system platform, and may be supported by a general purpose operating system such as, for example, the Windows XP or Windows Vista operating systems.
  • a virtual representation of a particular test instrument is abstracted so that the functions and functionalities of any virtual instrument are segregated from the other abstraction layers of the test system.
  • VMI virtual multisite instrument
  • a site is managed as a singular entity in that if a particular testing site is configured, a test program is developed for the particular site, specific to the particular testing hardware used. If multiple sites are needed to perform additional testing (e.g., to satisfy an increased testing capacity), then additional test hardware configurations are purchased, and the test program is matriculated to the additional sites.
  • test programs can be managed independent of test hardware, and the abstraction layer may be capable of managing the administration of a test program to multiple sites via the abstraction layer.
  • the virtual instrument may have capability to map to multiple instrument sites. In this way, the time needed to maintain and administer test programs to multiple sites is reduced.
  • one or more virtual multisite instruments may be defined, and resources (e.g., one or more instruments or sites ( 505 A- 505 C)) may be mapped to a virtual multisite instrument (VMI). Similar to virtual instruments, virtual multisite instruments communicate with instruments 505 A- 505 C through one or more physical instrument driver programs (e.g., PIs 503 A- 503 C). Similar to a virtual instrument, a virtual multisite instrument is not hardware implementation-specific, but rather, functionality is abstracted, and mapped to functions for particular hardware.
  • test program may be executed at multiple instrument sites (instruments 505 A and 505 C).
  • a modification of the test program would, according to one embodiment, cause the test program to be updated at multiple sites, as a result of the abstraction of multiple sites into a single entity. Because of this capability, management of test programs on multiple sites is simplified.
  • the functionality of an ATE tester are abstracted in a series of abstraction layers as shown in FIG. 4 .
  • the test program layer represents an abstraction of the functions and functionality employed by the ATE tester to interact with a user (typically through test programs).
  • the physical instrument layer represents an abstraction of the hardware implementation details necessary to communicate with physical hardware instruments on the ATE tester.
  • the functions of an ATE tester are broken down into a virtual instrument layer, that represents an abstraction of the functionality employed to map test requests from the test program layer to the physical instrument layer; a system layer, that represents an abstraction of the functionality employed by the physical instrument layer to communicate with the physical hardware it represents; and a platform layer, that represents an abstraction of the function and functionalities employed to provide a platform on which the other abstraction layers can operate.
  • the functions of an ATE tester are further abstracted into an interface layer, which represents an abstraction of the functionality employed to manage and standardize communication between the various abstraction layers. The layers shown in FIG. 4 will be discussed in greater detail below.
  • an ATE tester is described with reference to abstraction layers that represent the functions of the ATE tester.
  • the abstraction layers form the basis for the system architecture.
  • a test program forms a part of the test program layer.
  • a user interacts through the test program layer with the results of performed tests.
  • a user may schedule test requests to be performed on specific instruments of the ATE tester, through the test program layer. It should be well understood by those of skill in the art that multiple test programs can easily be incorporated into the test program layer.
  • the functionality provided by a conventional computer operating system is abstracted to be part of the platform layer.
  • the platform layer is abstracted so that almost any operating system can be employed for use with an ATE tester.
  • the platform layer provides the basic functionality employed by the various components of the ATE tester to operate and communicate.
  • the platform layer forms the base of the architecture.
  • Windows XP is employed as the operating system that forms a part of the platform layer. In this instance, the operating system manages basic functions employed by the various ATE tester components.
  • a library of C++ classes and C routines provide operating system services to the various components of the ATE tester.
  • the library of C++ classes and C routines are part of the platform layer which allows for the use of almost any base operating system as part of the platform layer.
  • Windows XP and INtime operating systems provide the base functionality employed by the ATE tester, although it should be appreciated that any real time operating system or general-purpose operating system with real-time extensions may be used.
  • many programming languages and many class libraries can be employed to provide system services for the various components of the ATE tester, and the platform layer is not restricted to a library of C++ classes and C routines to provide operating system services.
  • the platform layer has the capability of providing deterministic function.
  • deterministic function is provided by employing an “off the shelf” operating system enhanced to be deterministic.
  • Windows XP is employed as the off the shelf operating system, and is made deterministic by employing real-time extensions.
  • the INtime operating system provides the real-time extensions that make operations deterministic, however, it should be appreciated that any other real-time extensions may be used.
  • the platform layer manages the operation of the other abstraction layers of the ATE tester.
  • the functions of a particular test instruments are abstracted into a virtual representation so that their functions are segregated from the other abstraction layers of the test system.
  • the functions of one instrument can be represented in the virtual layer allowing other abstraction layers to access the instruments functionality through a virtualization.
  • communication with the virtualization can be standardized without being tied to any particular hardware implementation details.
  • the virtual instrument layer is further abstracted into virtual instrument modules (“VI modules”) used to represent a virtualization of a group of instruments employed to test a device.
  • a virtual instrument module can represent any number of physical pieces of hardware.
  • the VI module represents the functionality made available by the physical hardware of the ATE tester.
  • a user interfaces with a VI module through test programs, with the VI module managing the functions and function calls that cause any number of physical pieces of hardware to perform their respective test functions.
  • the virtual instrument layer does not contain any hardware specific implementation details. Rather, in one example, the virtual instrument layer contains the functionality employed to call another abstraction layer that does contain specific hardware implementation details. The separation described in the example allows for the easy incorporation of additional instruments into a VI module.
  • new hardware when new hardware is added to a tester, the addition of new function calls that map to the abstraction layer that contains the specific hardware implementation details enables the tester to employ the new functionality.
  • new functionality may be added by creating a new virtual instrument module. It should be realized that by creating new virtual instrument modules, adding new functionality has no impact on the existing functions of the ATE tester.
  • virtual modules can represent various versions of software, allowing software versioning to take place on an ATE tester while assuring that older versions and functionality are not impacted.
  • a virtual instrument module is implemented as a dynamic link library.
  • the virtual instrument module may be implemented as a runtime system library (RSL).
  • the physical instrument layer represents the abstraction of hardware specific implementation details of an ATE test system.
  • the physical instrument layer is further abstracted into physical instrument modules (“PI modules”).
  • PI modules physical instrument modules
  • every piece of actual hardware is accompanied by a PI module that implements the basic functionality of that piece of hardware.
  • the functionality made available by a particular piece of hardware is often referred to as a resource.
  • a PI module is implemented as a dynamic link library.
  • the PI module may be implemented as an RSL.
  • the virtual instrument layer calls the physical instrument layer to access the specific hardware implementation details of the hardware installed in the ATE tester. In one embodiment, this is accomplished by a VI module calling a PI module to access the hardware specific details that the PI module represents. In one example, a PI module represents the specific hardware implementation details of a physical piece of hardware capable of providing clock synchronization signals to the ATE tester. In one embodiment, a VI module manages the function calls to the PI module that cause the physical piece of hardware to generate a clock synchronization signal.
  • test program layer (User application/Test Application) directs requests to VI modules of the virtual instrument layer (Virtual Instrument/VI), which in turn directs requests to PI modules of the physical instrument layer (Physical Instrument/PI).
  • VI modules of the virtual instrument layer Virtual Instrument/VI
  • PI modules of the physical instrument layer Physical Instrument/PI
  • FIG. 6A shows another example architecture showing an example test system architecture according to one embodiment of the present invention.
  • a user application 601 accesses one or more Virtual Instruments (e.g., virtual instruments 602 A- 602 N).
  • a virtual instrument may include any number of physical instruments (e.g., physical instruments 603 A- 603 N). This permits, for example, the test system to implement functions that would otherwise be dispersed in the individual physical instruments.
  • the VMI has no specific knowledge of any actual hardware implementation. This knowledge resides with the “physical instrument module” (PI, e.g., physical instruments 603 A- 603 N). According to one example implementation, each piece of actual hardware is accompanied by a PI module that implements all the basic functionality of that hardware.
  • the VMI uses the functionality provided by one or more PIs to implement the functionality that will be presented to the user. In other embodiments, the VMI may have some knowledge, depending on the requirements of the test system developers and/or application.
  • PI modules themselves do not communicate directly to the hardware but rather through a “System PI” entity (e.g., system PI 604 ).
  • System PI 604 implements functionality that allows the PI to communicate with the instruments that reside on the test head of the test system hardware.
  • a VMI may communicate directly to hardware through the System PI.
  • the VMI may also inform the PI of the communication so that the PI matches the hardware state as necessary.
  • FIGS. 6A-6B are presented by way of illustration and not by limitation.
  • FIG. 6A also incorporates one example interaction between the physical instrument layer and the system layer to be discussed further below.
  • a VI module can incorporate a number of PI modules, and even share PI modules.
  • the present invention provides flexibility and adaptability for any tester based on this model.
  • new PI modules can be easily programmed in response to additional testing needs, and old PI modules can be leveraged in the design and fabrication of new testers.
  • a base class of function calls are provided that represent functionality typically employed for the testing of any device. In one embodiment, these base function calls can be incorporated into a PI Module and made available for use by test programs through a VI module.
  • the physical instrument layer does not communicate directly to physical pieces of hardware they describe.
  • a PI module passes requests, function calls, and/or data to the system layer.
  • the system layer represents an abstraction of the functions and functionality that allows the PI layer to communicate with the physical pieces of hardware (i.e. instruments) that are installed in the ATE tester.
  • a PI module of the physical instrument layer communicates to the system layer (show as System PI) which maps calls to the physical hardware of the ATE tester.
  • the system layer includes a SystemPI module.
  • the system layer represents an abstraction of the functionality employed to request and communicate information from other abstraction layers for reporting to the platform layer.
  • the functionality that manages passing of function calls, requests, and data transfers between the abstraction layers is also abstracted in an interface layer.
  • the interface layer includes the abstraction of the functionality used to manage communication in between and amongst the various other abstraction layers.
  • the interface layer manages the communication of function calls, the transfer of data, and any other communications between modules contained within each abstraction layer.
  • the interface layer insures that communications between the various modules of the ATE tester occur in an expected format. It should be appreciated that by ensuring communications occur in an expected format, various modules will communicate in the same way regardless of the hardware implemented on any particular tester.
  • the user layer e.g., the tester interface
  • the physical layer e.g., the VMI and PI implementations
  • more generalized hardware and software may be used for user layer components, or any other type of component that does not require specialized hardware and software.
  • the system may be architected in this way, the cost for producing such a tester can be significantly reduced, as off-the-shelf hardware (e.g., PCs) and software (e.g., OSs) may be used instead of specialized components.
  • the tester platform OS and associated tester components may be modified without affecting user layer components. That is, if the tester interfaces presented to the user layer are maintained, the test program and other user layer components function consistently across changes. In this way, the user layer components such as test programs may be ported more easily among test systems having different system components such as software and hardware. Further, test programs that are developed on such systems are more useful over time, as they need not be reprogrammed and tested when the underlying hardware and software related to the test system needs to be changed. To this end, more than one virtual machine may be provided, at least one for user-level components and another that executes at least one component of the tester platform.
  • test system As discussed previously, in a normal ATE implementation, the test system, test program and the associated components are developed and maintained as a single entity, requiring retest and certification upon the occurrence of the slightest changes. As a result, it is appreciated that normal ATE implementations are less flexible, require greater effort to maintain, and are less useful as a result.
  • FIG. 7 shows a block diagram of a test system platform according to one embodiment of the present invention illustrating changes in physical instrument versions.
  • a user may develop a test application 701 that is tailored to work with an example physical instrument version 1.0 (item 702 A).
  • a physical instrument version may be made available that is different than an earlier version.
  • physical instruments may have an additional capability that has been added in a later version of the hardware.
  • a physical instrument driver may be provided that includes a different interface to the new version of the physical instrument.
  • a physical instrument version 1.0 ( 702 A) may, by default, produce an output voltage to a device under test of 5 volts.
  • a physical instrument version Z (item 702 Z)
  • the default value of the output voltage may be different (e.g., 64 volts). Because of this change, the test application 701 may not work in the manner indicated.
  • a virtual instrument entity is provided that is independent of physical instrument versions, however, but is designed to support additional functionality as later hardware and driver software becomes available.
  • a virtual instrument is provided that decouples test hardware from its associated software applications 301 .
  • a method for providing software functions is provided that permits compatibility across software and hardware versions.
  • functions of a virtual instrument are provided which remain unchanged between versions. More particularly, as functions are added to the virtual instrument, old functions are maintained, and functionality is added to a predetermined memory structure. Functionality to software modules are added without changing references to preexisting functions in memory. Because function references are unchanged, additional functionality, when added to the memory structure does not break existing connections.
  • a virtual function table (e.g., in the C++ programming language, the well-known virtual method table “vtable”)) is maintained for a virtual instrument.
  • a base set of functionalities included having a defined location in the vtable.
  • additional functions are added to the vtable, while maintaining the same location of the vtable for the base set of functionality.
  • a base vtable may be followed by a derived vtable including the additional functionality.
  • FIG. 8 shows a block diagram of a vtable memory structure which may be used to implement various aspects of the present invention.
  • vtable 800 includes one or more methods 801 A- 801 E which correspond to functions associated with particular instrument driver.
  • a particular function e.g., method E ( 801 E)
  • the behavior of the method changes, and thus any hardware or software that communicates using the function does not perform in the manner originally planned for in the earlier version.
  • method E is called incorrectly, includes different default values, or returns data in a different format, the calling function will perform differently than expected.
  • a memory structure is provided that permits software features to be added without breaking existing connections.
  • FIG. 9A shows one architecture 900 according to one embodiment of the present invention.
  • application 901 may use one or more virtual instruments, each of which may have varying feature sets that facilitates software compatibility among software modules of a testing system.
  • a virtual instrument V.1.0 (Item 902 A) may be provided that is mapped to one or more physical instrument (PI) drivers. That is, a particular virtual instrument may be permitted to access one or more versions of a physical instrument driver.
  • PI physical instrument
  • virtual instrument v.1.0 may be configured to communicate to instrument v.1.0 (item 904 A) via physical instrument driver v.1.0 (item 903 A) having a function set of elements [a, b, c, d, e].
  • virtual instrument v.1.0 may be capable of communicating to instrument v.y (item 904 Z) having functions set [a, b, c, d, e′, f, g] using physical instrument driver v.y (item 903 Z). Therefore, an application 901 may be capable, depending on the application, may use any version of an instrument and its associated driver without conflict.
  • FIG. 9B shows a block diagram of a memory structure according to one embodiment of the present invention.
  • additional hardware may include one or more modified functions over previous functions or take advantage of additional functionality in nearly-introduced hardware and software.
  • a vtable 901 associated with a physical instrument version v.1.0 includes one or more functions [a, b, c, d, e].
  • a later version of a physical instrument is made available having a corresponding vtable 912 including functions set [a, b, c, d, e′, f, g].
  • a further version of the vtable associated with a physical instrument includes maintaining the same function references from previous versions to ensure that software that calls a particular function can locate that same function in the same location. So, for example, the function A (item 913 A) is mapped to function A of the next version of the vtable, and is located in the same memory location. Further, in another example wherein a particular function is modified in the later version, the existing function (e.g., function E (item 914 A)) is maintained in the same memory location in the later-version of the vtable. In this way, a newer version of a physical instrument may be added to the system without effecting existing software and applications that access the later version.
  • modified and/or added functionality is added to the following portions of the vtable so that the connections between old applications and newer versions of the physical instrument are maintained.
  • these modified or added functions are added after previous versions functionality.
  • a modified function 915 e′ is added after the original function 914 B e.
  • additional functions f and g are added functions 916 which can be added after the base functions a through e. In this manner, functionality, whether changed or added, does not disturb existing references within the vtable. Because of this, existing connections between old applications and new versions of the physical instrument are not broken.
  • a later version of a PI vtable may be used to access the same or previous versions of a particular instrument hardware by adhering to the conventions discussed above.
  • FIG. 10 shows a block diagram of a memory structure according to another embodiment of the present invention showing how backwards compatibility is maintained using the program and conventions as described above.
  • a version 2.0 of the PI vtable (item 1001 ) includes a number of methods including the set [a, b, c, d, e, e′, f, g]. Because the later version of the vtable includes all of the functionality from previous versions of the PI, and their locations within the PI vtable are maintained, the later-version PI is capable of communicating with current and earlier versions of the instrument hardware.
  • the method a which is used by instrument version 1.0 (item 1002 ) and instrument version 2.0 (item 1003 ) are the same, and backward compatibility between the version 2.0 PI (item 1001 ) and previous versions of the instrument are maintained.
  • Such backward compatibility can be performed, for example, by providing an abstract class which is inherited by later classes that include the modified or added functionality.
  • vtables are constructed such that the base data structure and associated methods include the same vtable function locations.
  • a standard vtable structure may be used which maintains the structure of a previous versions vtable. Because the structure is maintained, the applications or other programs that use the standard vtable structure can access newer and older methods as well as newer or older versions of hardware. However, it should be appreciated that other methods may be used for maintaining function references, and that a vtable need not be used.
  • a virtual instrument is revised to take advantage of newer functions, the same programming rules may be used to ensure that older versions of software (and therefore, hardware) can communicate with the virtual instrument version.
  • a virtual instrument version X (item 902 Z)
  • the virtual instrument version X will maintain the same vtable structure as previous versions, and in addition, may include additional functionality within the virtual instrument.
  • certain functions provided in various versions of a virtual instrument may have forward and backward compatibility between different versions of physical interface drivers.
  • a VI version 1.0 vtable may be capable of accessing certain functions provided by various versions of a physical interface driver.
  • a particular function created in the VI may call one or more functions in the PI that perform the higher-layer function of the VI.
  • functions A-E (items 925 A- 925 E) use functions a-e in either PI version 1.0 (item 922 ) or PI version 2.0 (item 924 ).
  • a physical instrument driver may be replaced that is compatible with the virtual instrument methods, as function references are maintained within the vtable structure.
  • a later version of a vtable associated with a virtual instrument is compatible with both earlier versions of a physical instrument driver as well as later versions of a physical instrument driver.
  • a modified method E′ (item 926 A) is added to the virtual instrument vtable which corresponds to e′ function of version 2.0 of the physical instrument driver (item 924 ).
  • a new version of a VI may be provided that takes advantage of additional functionality in a later version of a physical instrument driver.
  • modified and/or additional functionality may be added to the end of the vtable structure such that original functionality is not modified.
  • an older version of a physical instrument driver e.g., PI version 1.0
  • a later version of the VI e.g., version 2.0
  • a later version of the VI may communicate with an earlier version of the PI. In this way, both forward and backward compatibility is maintained between software entities within the ATE system.
  • Instrument independence is an important feature of a test system architecture, according to one embodiment of the present invention. This feature allows independent improvements or modifications of each instrument without the need for coordinated simultaneous upgrades.
  • the test system provides a system driver function via the system PI to manage the synchronization and triggering subsystem.
  • the system PI acts as a mediator between instruments.
  • the system PI manages the use and availability of signal lines, sets trigger connections and modes, and keeps delay information and does other housekeeping functions.
  • the user program calls functions of the virtual multisite instruments (VMIs) which in turn call functions of the instrument physical drivers (or PIs).
  • VMIs virtual multisite instruments
  • PIs are created, they are provided access to the system PI for system level functions, calibration and the use of system resources (e.g., memory, trigger subsystem, etc.).
  • system resources e.g., memory, trigger subsystem, etc.
  • test code may look something similar to:
  • Control->ConnectTrigger(9,‘Iddmeas’) the VMI first makes a call to the resource mapped to it (the resource being in the PI) and the PI requests a connection of a specific Trigger Line to a Signal Line via the system PI for each site named ‘Iddmeas[site]’. If they do not and sufficient signal lines are available, then the signal lines are reserved (by name) and the connection counter is set to 1, if the signal lines already exist the connection counter is incremented. In the event that there are insufficient signal lines available, an alarm may be generated. Upon successful reservation of signal lines, the VMI then instructs the Instrument PI(s) for each site to connect pattern bit 9 to the signal ‘Iddmeas[site]’.
  • Each PI checks for an available trigger line and make the connection on board.
  • the PI requests the System PI to make the connection of its chosen trigger line to the signal named ‘Iddmeas[site]’.
  • the Instrument PI does this by sending information to the System PI as to its location, trigger line selected and direction of the connection (in this case Asynchronous Dive) and the signal to be connected to.
  • the system PI sets the appropriate connection in the cross-point function and set the mode for the selected trigger line. Now we have pattern bit 9 driving the signal line named ‘Iddmeas[site]’.
  • the VMI called Vcc is set to current measure mode on the 100 ma range.
  • the VMI called Vcc is instructed to set the measurement strobe to trigger mode and connect the strobe to the signal named ‘Iddmeas’ in receive mode. This may be accomplished, for example, by having the Vcc VMI making a call to the System PI to reserve the Signal lines but since they were already reserved, the connection counter may be simply incremented. Then the Vcc VMI calls the individual instrument PIs to make the connection.
  • the VMI instruments makes the connection of the strobe to an available trigger line on-board and request the System PI to connect the selected trigger line to ‘Iddmeas’ in Asynchronous Receive mode.
  • the pattern is run and the measurement is stored on the board. This may be followed by a delay and then the measurement(s) are retrieved.
  • the connections persist and can be used in subsequent tests so it is not necessary to re-program the connection if the connection is needed again. A situation may arise where there are no longer enough signal lines available for use in subsequent tests. In this case, a Disconnect function may be used to free up signal lines that are no longer needed.
  • the system PI may maintain a count of connections and any disconnect function call from a VMI will be honored if the count is zero. To free up ‘Iddmeas’ in the example, the following lines may be added:
  • the Digital VMI ‘Control’ may instruct the instrument PIs to disconnect, The PIs request the disconnect from the System PI, Then the Control VMI requests the disconnect of the Signal named ‘Iddmeas’.
  • the system PI decrements the connection counter but does not free up the signal lines because a connection still exists.
  • the Vcc VMI similarly instructs the instrument PIs to disconnect, then request a disconnect from the system PI. In this instance the System PI decrements the connection counter to zero and de-allocate the signal line for later use.
  • the System PI manages the resources (signal lines) in a robust way. For example, all signal lines may be de-allocated at program load and at start of test. Also, since tools might be able to control connection state and users may quit at breakpoints etc., signal lines should not be locked out in error.
  • FIG. 11 shows another example of a test system architecture which may be used to implement various aspects of the present invention.
  • Deterministic operation is one basic requirement to achieve a high level of repeatability in test applications. By reducing the jitter associated with the execution time of individual tests in a test application, measurements made across multiple devices will be much more consistent and accurate.
  • the ATE industry has solved this problem by using dedicated processors running real-time operating systems to execute individual tests. The drawback with this approach is that deterministic operation is achieved at a very high cost.
  • RTOSs real-time operating systems
  • FIG. 11 shows an example architecture that includes both real-time and non-real time components.
  • the architecture may include a graphical user interface 1101 which is used by the user to perform and maintain test programs.
  • the architecture may include a data log process 1102 that stores test results retrieved from devices under test (DUTs).
  • the system may include a non-real-time function 1103 that performs flow control relating to executed test procedures.
  • the architecture may perform any number of non-realtime-tasks 1104 relating to testing, such as reporting, alarms, or other tasks.
  • real-time and non-real-time components may be implemented on separate virtual machines. These separate virtual machines may be, for example, executed on the same or different processors as is known in the art.
  • the virtual machines may perform inter-virtual machine communication to implement various distributed functionality.
  • non-real-time components on a separate system entity (e.g., a separate virtual machine)
  • the cost of such a system may be reduced, as off-the-shelf hardware and software may be used to implement such non-real-time components.
  • the architecture provides real-time processes for performing functions relating to testing one or more DUTs.
  • a test execution control component 1106 may be provided that governs the execution of test functions on the one or more DUTs.
  • the system may have defined one or more virtual multisite instruments (e.g., VMIs 1108 A- 1108 C) that can be used to implement one or more test programs provided by a user.
  • the architecture may include other ancillary real-time tasks 1107 that are performed to support the testing procedures. Such tasks may include, for example, signaling or other time-dependent tasks.
  • an inter-OS communication area 1105 (or an inter-virtual machine communication area in the case of using separate virtual machines) may be provided which allows real-time tasks to communicate with and access resources in the non-real-time domain.
  • the Windows XP operating system has a well-known graphical user interface
  • the Windows XP operating system is not a real-time operating system. This basically means that the Windows XP operating system cannot guarantee that a particular operating system request will be serviced in a particular amount of time, or that tasks running under the operating system are guaranteed to execute in a predetermined period of time.
  • the Windows XP operating system may be modified to allow the operating system (or any other operating system) to provide real-time capabilities.
  • Tenasys real time extensions may be used, but it should be appreciated that other types of extensions or any other real-time operating system (RTOS) may be used.
  • RTOS real-time operating system
  • Tenasys offers a solution that provides the ability to run two completely different operating systems in a single processor while allowing communication between the two OSs.
  • Tenasys technology that allows both operating systems to run on an x86 platform without interference. This technology also guarantees that failures (even catastrophic failures) in one environment do not cause any side effects on the other environment. This allows for a very high degree of reliability.
  • the INtime product provides a real-time environment in which the Windows NT operating system itself is a low-priority task. This way all real-time tasks take precedence over Windows NT operating system so it is possible to guarantee consistent execution times regardless of any activity in the Windows environment.
  • the test system architecture relies on a real-time environment where all time critical tasks are executed and a non-real-time environment where relatively low-priority tasks will execute. Both of these operating system environments would share a single processor system and communicate with each other when necessary.
  • a test architecture may be adapted to perform deterministic processing as discussed in U.S. patent application Ser. No. 11/218,915 filed Sep. 2, 2005, entitled “SYSTEM AND METHOD FOR PERFORMING DETERMINISTIC PROCESSING”, the contents of which are incorporated herein by reference.
  • U.S. patent application Ser. No. 11/218,915 filed Sep. 2, 2005 entitled “SYSTEM AND METHOD FOR PERFORMING DETERMINISTIC PROCESSING”, the contents of which are incorporated herein by reference.
  • other operating systems may be used with real-time capabilities, and the invention is not limited to any particular type of operating system.
  • Various embodiments according to the present invention may be implemented on one or more computer systems. These computer systems may be, for example, general-purpose computers such as those based on Intel PENTIUM-type processor, Motorola PowerPC, AMD Athlon or Turion, Sun UltraSPARC, Hewlett-Packard PA-RISC processors, or any other type of processor. It should be appreciated that one or more of any type computer system may be used to perform processing according to various embodiments of the invention. Further, the system may be located on a single computer or may be distributed among a plurality of computers attached by a communications network.
  • a general-purpose computer system is configured to perform any of the described functions, including but not limited to, performing processing associated with a test program. It should be appreciated that the system may perform other functions, and the invention is not limited to having any particular function or set of functions.
  • FIG. 12 shows a block diagram of a general purpose computer and network system in which various aspects of the present invention may be practiced.
  • various aspects of the invention may be implemented as specialized software executing in one or more computer systems including general-purpose computer system 1201 shown in FIG. 12 .
  • Computer system 1201 may include a processor 1204 connected to one or more memory devices 1205 , such as a disk drive, memory, or other device for storing data.
  • Memory 1205 is typically used for storing programs and data during operation of the computer system 1201 .
  • Components of computer system 1201 may be coupled by an interconnection mechanism such as network 1210 , which may include one or more busses (e.g., between components that are integrated within a same machine) and/or a network (e.g., between components that reside on separate discrete machines).
  • the interconnection mechanism enables communications (e.g., data, instructions) to be exchanged between system components of system 1201 .
  • Computer system 1201 also includes one or more input/output (I/O) devices 1206 , for example, a keyboard, mouse, trackball, microphone, touch screen, a printing device, display screen, speaker, etc.
  • I/O input/output
  • computer system 1201 may contain one or more interfaces (e.g., network communication device 1208 ) that connect computer system 1201 to a communication network (in addition or as an alternative to the network 1210 .
  • the storage system 1209 typically includes a computer readable and writeable nonvolatile recording medium in which signals are stored that define a program to be executed by the processor or information stored on or in the medium to be processed by the program.
  • the medium may, for example, be a disk or flash memory.
  • the processor causes data to be read from the nonvolatile recording medium into another memory that allows for faster access to the information by the processor than does the medium.
  • This memory is typically a volatile, random access memory such as a dynamic random access memory (DRAM) or static memory (SRAM).
  • DRAM dynamic random access memory
  • SRAM static memory
  • the memory may be located in storage system 1209 , as shown, or in memory system 105 .
  • the processor 104 generally manipulates the data within the integrated circuit memory 104 , and then copies the data to the medium associated with storage 1209 after processing is completed.
  • a variety of mechanisms are known for managing data movement between the medium and integrated circuit memory element and the invention is not limited thereto. The invention is not limited to a particular memory system or storage system.
  • the computer system may include specially-programmed, special-purpose hardware, for example, an application-specific integrated circuit (ASIC).
  • ASIC application-specific integrated circuit
  • computer system 1201 is shown by way of example as one type of computer system upon which various aspects of the invention may be practiced, it should be appreciated that aspects of the invention are not limited to being implemented on the computer system as shown in FIG. 12 . Various aspects of the invention may be practiced on one or more computers having a different architectures or components that that shown in FIG. 12 .
  • Computer system 1201 may be a general-purpose computer system that is programmable using a high-level computer programming language. Computer system 1201 may be also implemented using specially programmed, special purpose hardware.
  • processor 1204 is typically a commercially available processor such as the well-known Pentium class processor available from the Intel Corporation. Many other processors are available.
  • Such a processor usually executes an operating system which may be, for example, the Windows-based operating systems (e.g., Windows NT, Windows 2000 (Windows ME), Windows XP, Windows Vista operating systems) available from the Microsoft Corporation, MAC OS System X operating system available from Apple Computer, the Solaris operating system available from Sun Microsystems, UNIX operating systems available from various sources, INtime and Tenasys as mentioned above, among others. Many other operating systems may be used, and the invention is not limited to any particular operating system or operating system extensions to perform any real-time or non-real-time functions according to various embodiments.
  • Windows-based operating systems e.g., Windows NT, Windows 2000 (Windows ME), Windows XP, Windows Vista operating systems
  • Microsoft Corporation e.g., Windows NT, Windows 2000 (Windows ME), Windows XP, Windows Vista operating systems
  • MAC OS System X operating system available from Apple Computer
  • Solaris operating system available from Sun Microsystems
  • UNIX operating systems available from various sources, INtime and Tenasys
  • the processor and operating system together define a computer platform for which application programs in high-level programming languages are written. It should be understood that the invention is not limited to a particular computer system platform, processor, operating system, or network, unless specified by one or more claims. Also, it should be apparent to those skilled in the art that the present invention is not limited to a specific programming language or computer system. Further, it should be appreciated that other appropriate programming languages and other appropriate computer systems could also be used.
  • One or more portions of the computer system may be distributed across one or more computer systems coupled to a communications network.
  • These computer systems also may be general-purpose computer systems.
  • various aspects of the invention may be distributed among one or more computer systems (e.g., servers) configured to provide a service to one or more client computers, or to perform an overall task as part of a distributed system.
  • various aspects of the invention may be performed on a client-server or multi-tier system that includes components distributed among one or more server systems that perform various functions according to various embodiments of the invention.
  • These components may be executable, intermediate (e.g., IL) or interpreted (e.g., Java) code which communicate over a communication network (e.g., the Internet) using a communication protocol (e.g., TCP/IP).
  • a communication protocol e.g., TCP/IP
  • Various embodiments of the present invention may be programmed using an object-oriented programming language, such as SmallTalk, Java, C++, Ada, or C# (C-Sharp). Other object-oriented programming languages may also be used. Alternatively, functional, scripting, assembly language, and/or logical programming languages may be used.
  • object-oriented programming languages such as SmallTalk, Java, C++, Ada, or C# (C-Sharp).
  • Other object-oriented programming languages may also be used.
  • functional, scripting, assembly language, and/or logical programming languages may be used.
  • Various aspects of the invention may be implemented in a non-programmed environment (e.g., documents created in HTML, XML or other format that, when viewed in a window of a browser program, render aspects of a graphical-user interface (GUI) or perform other functions).
  • GUI graphical-user interface
  • Various aspects of the invention may be implemented as programmed or non-programmed elements, or any combination thereof.
  • the system may be a single or multiprocessor system.
  • the system includes software processes executing on a system such as a personal computer (PC).
  • PC personal computer
  • Such a system may permit the user to perform one or more functions in a test system that tests a device under test (DUT).
  • DUT device under test
  • Such systems may include, for example, test systems, control systems, among others.
  • test programs software is used by different types of user—some users develop test applications, and others use the developed applications for the administration and management of test processes.
  • these separate types of users may need to use a specific user interface (UI), depending on what functions are performed.
  • UI user interface
  • multiple types of testers have different user interfaces, forcing the user to understand the specific type of interface necessary to run the equipment.
  • the application and drivers are tightly coupled, and the user interfaces are tied to the system software.
  • a standard user interface may be used to access multiple tester types, reducing the amount of training necessary for the user.
  • a user-specific interface is provided that allows the user to perform testing functions related to their role.
  • a testing architecture that permits a user to perform testing functions from any location.
  • the user interface is accessed through a browser program, and a user may perform testing functions from any location coupled to a testing system through a communications network.
  • the UI is normally tied to the machine, however, if the UI is made available over a network, the user can perform testing from another location.
  • FIG. 13 shows an architecture diagram of an example system 1300 according to one embodiment of the invention that includes a server that executes test functions, and one or more client systems that render user interfaces used to perform test functions. It should appreciated that FIG. 13 is used for illustration purposes only, and that other architectures may be used to facilitate one or more aspects of the present invention.
  • a computer system 200 may be used to implement a test system.
  • Computer system 1301 may include one or more software processes 1305 that perform test system functions, database functions, and interface functions as discussed below.
  • system 1301 may be a general-purpose computer system as discussed above with reference to FIG. 12 .
  • system 1301 may include an operating system, one or more processors, and one or more I/O components.
  • system 1301 permits one or more client systems (e.g., systems 1307 A- 1307 D) and their associated users (e.g., users 1308 A- 1308 D) to access test functions.
  • the test system 1301 and its associated hardware and software are communicated with via one or more communication networks 1304 .
  • Network 1304 may include, for instance, the Internet, a corporate enterprise network or other communication network type.
  • users can access test system functions at disparate locations through communication network 1304 .
  • the test system user interface is a web-based interface, capable of being downloaded and viewed over a communication network.
  • a client e.g., client 1307 D
  • a browser program e.g., the Microsoft Internet Explorer browser program
  • the user may log into test system 1301 , and system 1301 may provide one or more software programs or components 1303 that may be used by a client to access test system functions.
  • test system functions are performed using the well known Windows forms interface available from the Microsoft Corporation, and may be accessible through a browser program (e.g., 1309 ).
  • the client may download and store any application program 1310 software and/or database elements (e.g., elements stored in database 1311 ) to render the user interfaces discussed.
  • Windows forms may be used, it should be appreciated that any type of software and/or communication methods may be used (e.g., CGI, Perl, XML, etc.), and the invention is not limited to any particular method.
  • the user can, from any web-enabled client, perform test functions.
  • a user can control any tester from any location as long as the user has a connection to the test system 1301 .
  • user interfaces are tied to and are specific to the testing hardware, and thus are executed locally to the test equipment.
  • a user logs into the test system 1301 through a communications network (e.g., the Internet).
  • each user is presented their own set of GUIs to control testing.
  • the test system 1301 may store different UIs (e.g., as an entry 1306 in database 1302 ), and depending on the user that logs in, different UIs may be presented to that user.
  • the UIs may include one or more programs (e.g., application program 1310 ) having one or more locally-stored components.
  • the UIs may include one or more databases in which to store UI configuration data.
  • the user can view custom UIs at any location having network connectivity, and the custom UIs are tailored to suit the particular role of the user.
  • the PowerPoll process, 1400 illustrates the interaction between some of the modules within the abstraction layer architecture.
  • the following is an example process that may be performed, for example, using the process flow, 1400 , described with respect to FIG. 15 . It should be appreciated that the process discussed below is made by way of example only and not by limitation.
  • the PowerPoll process, 1400 is typically initiated in the platform layer by the expiration of a timer at 1402 .
  • the PowerPoll process may also check to see if an end of time (EOT) event has occurred or if a program has reached a break point. If the power polling timer has not expired 1404 (FALSE), main thread execution continues at 1406 . If the power polling timer has expired, 1404 (TRUE), the platform layer passes a call to the system layer, including two platform state variables “System PowerState” and “System Power Interrupted.” In response the system layer through a SystemPI Module calls the Update SystemPowerStatus function, at 1408 .
  • EOT end of time
  • the SystemPI will return 2 bits of data to the platform layer; Bit 1 : reflecting Power Interrupted & Bit 0 : reflecting PowerState.
  • Bit 1 reflecting Power Interrupted
  • Bit 0 reflecting PowerState.
  • the process flow optionally continues by determining if the platform state variable is at “ProgramAtBreakPoint,” (not shown), if not a dispatcher control component reads the mailbox and clears it at step 1410 .
  • the dispatcher control component takes the latest configuration (if any) and compares that configuration to the current configuration, at step 1410 .
  • a check is done to determine if PI modules were deleted at 1414 , if PI modules were not deleted, 1414 (FALSE) the new PI modules are loaded at 1420 , where PI modules were deleted 1414 (TRUE) PowerOnInit function (within the physical instrument layer) is called on all deleted PI modules at 1416 and the deleted PI modules are unloaded at 1418 . New PIs are loaded at step 1420 . Alternatively, after step 1408 's call to SystemPI Update the process may proceed directly to 1410 to determine if dispatcher received new configurations.
  • the alternative forks of the process 1412 (TRUE) and 1412 (FALSE) meet again and the process determines whether power is available at the hardware represented by the PI modules at 1422 . If power is off 1422 (FALSE), the PowerOnInit function is called at 1428 , if power is available 1422 (TRUE), the system checks to see if power was off or interrupted at 1424 . If power was off or interrupted 1424 (TRUE) the PowerOnInit function is called at 1428 . If power was not off or interrupted 1424 (FALSE), the process continues to check if the configuration is different at 1426 . The previous forks meet again at the configuration test. If the configuration is not different 1426 (FALSE) the process returns to main thread execution at 1438 .
  • the system will optionally re-qualify and update the platform state variable “StateRecipeQualified.” (not shown).
  • a check to determine if the program is loaded is performed at step 1430 . If the program is not loaded 1430 (FALSE) main thread execution will continue at 1438 . If the program is loaded 1430 (TRUE) a function call IsMappingOK( ) is made for all VMIs at 1432 . If the mapping is ok for all VMIs, 1434 (TRUE) main thread execution continues at 1438 . If mapping is not ok for all VMIs 1434 (FALSE), state variable ProgramNotValid is updated at 1436 .
  • the exemplary process determines if a system is in a powered on state. Also, if in the powered-on state, the test program and VMIs can successfully meet their requirements to test on the hardware existing post-power-cycle or reconfiguration. The VMI holds the responsibility of this checking, providing another abstraction of responsibility away from the platform and provided to the modules.
  • the next check is to validate the actual configuration of the system. As a result of this process, configured PI modules with missing or incorrect hardware will put themselves into a disabled state and publish their resources as “PoweredOff.” If additional hardware is detected that does not correspond to a configured PI module, then a ValidateConfiguration process (not shown) will publish a warning message. The warning message can be returned to a platform user messaging window or to a platform configurator to display an intelligent display name if available or an “unknown hardware” message if not.
  • FIG. 15 is presented by way of illustration and not by way of limitation.
  • each respective module has an interface 1538 with the platform layer interface 1532 (shown as Platform Software w/Dispatcher) that manages the bi-directional communication with respect to the CheckAlarms function call.
  • the SystemPI module 1504 also has an interface 1540 for managing communication and functions with the PI module's interface 1542 .
  • the platform layer represents an abstraction of the functionality employed to log the results of a process flow. As can be seen with reference to FIG. 15 , in one embodiment various function calls performed as part of a process flow report their results to the platform layer. In one embodiment, the platform layer represents an abstraction of the functionality employed to log the reported results of the various function calls from the other abstraction layers.
  • Alarm process 1500 begins with a CheckAlarms( ) call at 1502 to the SystemPI.
  • the SystemPI 1504 has full knowledge of the configuration of the tester and holds a list of all occupied locations (location is a platform concept and may be represented by a 32-bit number acting as an index into a list).
  • the Platform/dispatcher 1508 expects a return of a list of Locations form the SystemPI 1504 which may have alarmed.
  • the SystemPI returns a list containing locations that may have alarmed to the Platform/dispatcher 1508 .
  • this list may be filtered by the SystemPI 1504 .
  • filtering is done based on the SystemPI's 1504 ability to determine is a PI 1512 is under its purview.
  • the system is configured to return PIs 1512 that are not within a SystemPI's 1504 purview automatically.
  • a Ceres Native Instrument is within the purview of the Ceres SystemPI.
  • a key concept here is that instruments which are not native to a tester can be easily integrated into an overall test solution—the platforms' interface with the PI module has no expectations of hardware implementation. Therefore, in one specific example, a GPIB or PCIExpress-based solution can be integrated exactly as a native-built solution allowing for a hardware-independent solution.
  • the ServiceAlarms( ) call is made to each location returned in the CheckAlarms( ) call to the SystemPI ( 1502 & 1506 ).
  • the ServiceAlarms( ) is received and the PI 1512 (or alternatively the SystemPI 1504 (not shown)) accesses its hardware to determine whether an actual alarm state exists.
  • filtering of alarms by the SystemPI aids in execution time, assisting in maintaining the deterministic nature of the test platform.
  • the system is configured to not generate Alarms that are not relevant to the accuracy of a measurement or do not indicate that the hardware is in an invalid state.
  • the PI 1512 (alternatively the SystemPI 1504 (not shown)) reads back the alarm state of the hardware at 1514 .
  • Step 1514 may also include clearing local alarm cache(s), and may include placing hardware into a safe state.
  • the PI 1512 (alternatively the SystemPI 1504 (not shown)) caches alarms by resource, as well as AllSite alarms (global alarms). In one embodiment the cache is maintained until the next ServiceAlarms( ) call is made. Caching enables alarms to be available for tool display.
  • the ReportAlarms( ) call is made to each instantiated VMI 1518 .
  • this call is made independent of whether any locations were returned in the CheckAlarms( ) call to the SystemPI 1504 at 1502 and 1506 .
  • independent calls to ReportAlarms( ) is beneficial because it accounts for alarms treated as persistent by a PI (e.g. 1512 ) and when the hardware may not indicate an Alarm to the SystemPI 1504 (this may occur in embodiments where the SystemPI filters alarms based on PIs within its purview) or because a software-level alarm may have occurred either in the VMI or with the VMI's mapped resources.
  • the VMI 1518 queries each of its resources, for example PI 1512 at 1520 , to determine if an alarm exists. It should be understood that VMI 1518 may have one or more PIs with which it interacts, and figure should not be interpreted as limiting a VMI to any number of PI interactions and their associated resources.
  • PI 1512 In response to the VMI query PI 1512 responds with the requested alarm information at 1522 and marks the alarm as reported. PI 1512 may filter out alarms reported back based on design or based on configurations of the PI 1512 . In addition VMI 1518 may also filter reported alarms based on design or based on configuration of the VMI 1518 .
  • the VMI 1518 provides a response regarding its resources with a ms_bool at 1524 . In one embodiment, a response is performed with a bool which is multisite deep. That is, multisite objects (e.g., ms_bool, ms_float, etc) may be created which are sized by the number of sites the program is developed to support.
  • multisite objects e.g., ms_bool, ms_float, etc
  • VMI 1518 may compile alarms by site as VMI object may be designed with comprehension of site.
  • the response from ReportAlarms is reported to the Datalogging service 1554 at 1530 .
  • the response from ReportAlarms may be combined with other information and reported to the Datalogging service 1554 .
  • GetUnreportedAlarms( ) call is made at 1526 to each instantiated PI 1512 (shown is one PI, however many PIs are possible) and the SystemPI 1054 .
  • the GetUnreportedAlarms( ) call may be made independent of whether any locations were returned in the CheckAlarms( ) call ( 1502 and 1506 ) and alternatively to the SystemPI 1504 (not shown). In one embodiment, the GetUnReportedAlarms( ) call is only made to the SystemPI and the PIs.
  • the GetUnReportedAlarms( ) call allows for reporting of Alarms by resources which are not mapped to a VMI—the ReportAlarms( ) call to the VMI may be adapted to handle all the alarms for resources mapped to the VMI, whether they are persistent or non-persistent. Persistent alarms or Software Alarms are handled by the fact that even if the SystemPI returns a empty Location List to the CheckAlarms( ) call—the ReportAlarms and GetUnreportedAlarms are still carried out.
  • PI 1512 returns a 2-bit number in response at 1526 where the MSB indicates an AllSites Alarm and the LSB indicates and unreported resource alarm.
  • the response may be combined with other information and reported to the Datalogging service 1554 , for example the response from ReportAlarms and GetUnreportedAlarms may be combined and sent together to Datalogging service 1554 .
  • the physical instrument layer calls a PowerOnInitialize function as part of the system process that polls a system's power state.
  • the PowerOnInitialize function is included in a physical instrument base class of methods.
  • the PowerOnInitialize function is designed to place a PI module and its hardware into an known initial power state.
  • it is important that the test hardware powers into a known safe state because there is no guarantee that the platform layer is running or that a PI module is configured and loaded.
  • the PowerOnInitialize function is a member of a base class of functions defined in the physical instrument abstraction layer.
  • FIG. 16 shows an example illustration of one embodiment's implementation of the PowerOnInitialize function, 1600 .
  • FIG. 16 describes an exemplary data flow, and should not be read to limit the present invention either to the one function illustrated or this particular data flow.
  • PowerOnInitialization( ) call is made at 1602 .
  • a GetPlatformStateInformation( ) call is made to obtain the system power status.
  • the GetPlatformStateInformation( ) call is part of the PI Base Class of functions.
  • the PI local cache is set to initialized state at 1612 and state of published resources is updated at 1614 . If the system power in on 1608 (TRUE) that PI/hardware device is reset. In one embodiment, resetting is performed to guaranty the PI/hardware device is in a known state for testing. Once the PI/hardware device is reset the PI local cache is set to initialized state at 1612 and state of published resources is updated at 1614 . In one embodiment PI resources have either a State of PowerOn or PowerOff to identify their power state.
  • the virtual instrument layer includes a base class of functions that define basic functionality employed to perform its functions.
  • a VI module calls the GetPlaformInformation function to get platform state information.
  • the virtual instrument layer includes a function for reporting a list of alarms against its resources.
  • the alarm reporting function is included in the base class of functions.
  • the system layer includes a base class of functions that define basic functionality employed to perform its functions.
  • the platform calls the UpdateSystemPowerStatus function as part of the PowerPoll process shown in FIG. 14 .
  • the UpdateSystemPowerStatus function is included in the system layer base class of functions.
  • the base class of functions includes a CheckAlarm function, adapted to check whether locations have alarms returning a list of alarms.
  • the abstraction of functionality includes abstracting the functionality employed to operate software wizards adapted to generate interfaces between the various abstraction layers.
  • the abstraction of functionality includes an interface generation engine adapted to generate interfaces that manage communication between the various abstraction layers.
  • the interface generation engine represents the abstraction of the functionality employed to define an interface between a module in the system layer and a module in the physical instrument layer.
  • the interface generation engine represents the abstraction of the functionality employed to define an interface between a module in the virtual instrument layer and a module in the physical instrument layer.
  • the interface generation engine represents the abstraction of the functionality employed to define an interface between a module in the virtual instrument layer and a module in the system layer.
  • the interface generation engine represents the abstraction of the functionality employed to define an interface between a SystemPI module, PI Module, VI Module and the platform layer.
  • the abstraction of functionality includes abstraction of the functionality employed to operate software wizards adapted to generate modules of the various abstraction layers.
  • the abstraction of functionality includes a module generation engine adapted to define a module in one of the abstraction layers.
  • the module generation engine represents the abstraction of the functionality employed to define a VI module.
  • the module generation engine represents the abstraction of the functionality employed to define a PI module.
  • the module generation engine represents the abstraction of the functionality employed to define a SystemPI module.
  • the module generation engine may represent the abstraction of the functionality employed to define a platform module.
  • the generated modules need to be verified to insure appropriate mapping between the various abstraction layers.
  • generated modules must be verified to insure appropriate functionality.
  • a rules checking engine represents an abstraction of the functionality employed to verify the appropriate mapping of generated modules and to insure appropriate functionality. For instance, in one implementation, the SystemPI and PI perform rule checking to verify that they can work with each without adverse interaction. The VMI may perform rule checking to verify that the mapping of resources to it maintains needed rules to function correctly.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Tests Of Electronic Circuits (AREA)
US11/827,094 2006-07-10 2007-07-10 System and method for performing processing in a testing system Abandoned US20080033682A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/827,094 US20080033682A1 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US81961006P 2006-07-10 2006-07-10
US81976206P 2006-07-10 2006-07-10
US11/827,094 US20080033682A1 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system

Publications (1)

Publication Number Publication Date
US20080033682A1 true US20080033682A1 (en) 2008-02-07

Family

ID=38923557

Family Applications (7)

Application Number Title Priority Date Filing Date
US11/827,090 Active 2029-06-29 US7869986B2 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system
US11/827,083 Active 2031-05-16 US9032384B2 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system
US11/827,136 Active 2028-10-13 US7844412B2 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system
US11/827,134 Active 2030-07-10 US8065663B2 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system
US11/827,105 Active 2028-12-10 US8442795B2 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system
US11/827,094 Abandoned US20080033682A1 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system
US14/708,566 Abandoned US20160003892A1 (en) 2006-07-10 2015-05-11 System and method for performing processing in a testing system

Family Applications Before (5)

Application Number Title Priority Date Filing Date
US11/827,090 Active 2029-06-29 US7869986B2 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system
US11/827,083 Active 2031-05-16 US9032384B2 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system
US11/827,136 Active 2028-10-13 US7844412B2 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system
US11/827,134 Active 2030-07-10 US8065663B2 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system
US11/827,105 Active 2028-12-10 US8442795B2 (en) 2006-07-10 2007-07-10 System and method for performing processing in a testing system

Family Applications After (1)

Application Number Title Priority Date Filing Date
US14/708,566 Abandoned US20160003892A1 (en) 2006-07-10 2015-05-11 System and method for performing processing in a testing system

Country Status (6)

Country Link
US (7) US7869986B2 (zh)
JP (1) JP2009544012A (zh)
KR (1) KR20090082341A (zh)
CN (1) CN101512359A (zh)
TW (1) TW200817931A (zh)
WO (1) WO2008008773A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180307654A1 (en) * 2017-04-13 2018-10-25 Battelle Memorial Institute System and method for generating test vectors
US11120037B2 (en) 2019-06-21 2021-09-14 Wistron Corporation Test data integration system and method thereof

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7842948B2 (en) 2004-02-27 2010-11-30 Nvidia Corporation Flip chip semiconductor die internal signal access system and method
US7279887B1 (en) * 2004-08-06 2007-10-09 Nvidia Corporation In-process system level test before surface mount
DE102004041822A1 (de) * 2004-08-27 2006-03-02 Robert Bosch Gmbh Funktionseinheit zur Ausführung von logischen Testfällen auf einem an eine zu prüfende Einheit angekoppelten Testsystem und entsprechendes Verfahren
CN101512359A (zh) * 2006-07-10 2009-08-19 阿斯特瑞昂公司 用于在测试系统中实施处理之系统及方法
US8131387B2 (en) * 2007-08-09 2012-03-06 Teradyne, Inc. Integrated high-efficiency microwave sourcing control process
US8271252B2 (en) * 2007-11-08 2012-09-18 Nvidia Corporation Automatic verification of device models
US8510616B2 (en) * 2008-02-14 2013-08-13 Nvidia Corporation Scalable scan-based test architecture with reduced test time and test power
US8745200B2 (en) * 2008-05-06 2014-06-03 Nvidia Corporation Testing operation of processors setup to operate in different modes
US8589886B2 (en) * 2008-07-07 2013-11-19 Qualisystems Ltd. System and method for automatic hardware and software sequencing of computer-aided design (CAD) functionality testing
US8943457B2 (en) * 2008-11-24 2015-01-27 Nvidia Corporation Simulating scan tests with reduced resources
TWI405969B (zh) * 2009-05-08 2013-08-21 Accton Wireless Broadband Corp 管線式元件測試系統及其方法
US8413117B1 (en) * 2009-08-07 2013-04-02 Symantec Corporation Systems and methods for focusing product testing based on areas of change within the product between product builds
EP2375335A1 (en) * 2010-04-09 2011-10-12 Eurocopter Deutschland GmbH Method for automated testing of a system and automated testing system for such a method
US8683440B2 (en) * 2010-05-27 2014-03-25 Red Hat Israel, Ltd. Performing dynamic software testing based on test result information retrieved in runtime using test result entity
US8850396B2 (en) 2010-05-27 2014-09-30 Red Hat Israel, Ltd. Performing software testing based on grouping of tests using test list entity
US9009668B2 (en) 2010-05-27 2015-04-14 Red Hat Israel, Ltd. Software testing using test entity
CN103038786A (zh) * 2010-06-21 2013-04-10 惠普发展公司，有限责任合伙企业 用于测试和证明客户计算机系统上的虚拟设备的系统
US9317351B2 (en) * 2010-09-07 2016-04-19 Advantest Corporation System, methods and apparatus using virtual appliances in a semiconductor test environment
US8489929B2 (en) * 2010-09-30 2013-07-16 Salesforce.Com, Inc. Facilitating large-scale testing using virtualization technology in a multi-tenant database environment
US8479172B2 (en) * 2010-11-23 2013-07-02 International Business Machines Corporation Virtual machine testing
US9122473B2 (en) * 2010-11-26 2015-09-01 Mitsubishi Electric Corporation Program generating device, program generating program, and program generating method
US8607203B1 (en) * 2010-12-17 2013-12-10 Amazon Technologies, Inc. Test automation framework using dependency injection
US8782117B2 (en) 2011-08-24 2014-07-15 Microsoft Corporation Calling functions within a deterministic calling convention
US10776233B2 (en) * 2011-10-28 2020-09-15 Teradyne, Inc. Programmable test instrument
US9759772B2 (en) 2011-10-28 2017-09-12 Teradyne, Inc. Programmable test instrument
US9910086B2 (en) 2012-01-17 2018-03-06 Allen Czamara Test IP-based A.T.E. instrument architecture
CN102749544A (zh) * 2012-07-20 2012-10-24 广州供电局有限公司 基于虚拟仪器技术的电力设备测试系统
US9110731B1 (en) 2012-08-15 2015-08-18 Xiotech Corporation Hard allocation of resources partitioning
CN102788935A (zh) * 2012-08-23 2012-11-21 广州供电局有限公司 电桥法电缆故障定位仿真方法
US9959186B2 (en) * 2012-11-19 2018-05-01 Teradyne, Inc. Debugging in a semiconductor device test environment
US20140157238A1 (en) * 2012-11-30 2014-06-05 Microsoft Corporation Systems and methods of assessing software quality for hardware devices
US9082291B2 (en) * 2012-12-17 2015-07-14 Itron, Inc. Virtual metering with partitioned metrology
US9747786B2 (en) 2012-12-17 2017-08-29 Itron, Inc. Virtual cluster meter (VCM)
US9677907B2 (en) 2013-03-14 2017-06-13 Itron Inc Intelligent receptacle
US9785526B2 (en) * 2013-04-30 2017-10-10 Advantest Corporation Automated generation of a test class pre-header from an interactive graphical user interface
US20160179658A1 (en) * 2013-11-27 2016-06-23 Ca, Inc. User interface testing abstraction
WO2015179603A1 (en) 2014-05-22 2015-11-26 Citrix Systems, Inc. Providing testing environments using virtualization
US10235868B2 (en) * 2014-09-29 2019-03-19 National Instruments Corporation Embedded shared logical instrument
CN105893234B (zh) * 2014-12-30 2019-05-07 伊姆西公司 用于软件测试的方法和计算设备
US10429437B2 (en) * 2015-05-28 2019-10-01 Keysight Technologies, Inc. Automatically generated test diagram
US9983981B1 (en) * 2015-06-23 2018-05-29 Amdocs Development Limited System, method, and computer program for implementing optimal regression test strategies
US9864655B2 (en) * 2015-10-30 2018-01-09 Google Llc Methods and apparatus for mobile computing device security in testing facilities
CN105630679B (zh) * 2015-12-23 2019-04-23 北京奇虎科技有限公司 代码测试的方法及装置
CN105759790B (zh) * 2016-04-21 2018-06-29 合肥通用机械研究院有限公司 电子冷却装置控制系统的组态测试系统及其测试方法
TWI637177B (zh) * 2016-12-23 2018-10-01 台灣福雷電子股份有限公司 用於測試半導體元件之系統及方法
KR101956779B1 (ko) * 2017-01-17 2019-03-11 한국항공우주산업 주식회사 모듈화를 통한 자동시험장비의 운용 시스템
US10451668B2 (en) 2017-04-28 2019-10-22 Advantest Corporation Test program flow control
US10754765B2 (en) * 2017-05-17 2020-08-25 Google Llc Operating system validation
EP3871082A4 (en) * 2018-10-23 2022-07-27 Enosix, Inc. MICROCOMPONENTS FOR DATA INTEGRATION AND ASSOCIATED PROCESSES
CN109483552B (zh) * 2018-12-27 2020-10-23 合肥欣奕华智能机器有限公司 一种基板搬送机器人系统软硬件调试方法及设备
CN109885435A (zh) * 2019-02-18 2019-06-14 国家计算机网络与信息安全管理中心 通用容器化计算集群的测试系统及方法
CN110045260A (zh) * 2019-04-03 2019-07-23 南京邮电大学 半导体器件虚拟测试平台及半导体器件虚拟测试方法
US11314628B2 (en) 2019-12-02 2022-04-26 Bank Of America Corporation System for intelligent unit performance testing of computer applications
CN113495162A (zh) * 2020-03-20 2021-10-12 竑腾科技股份有限公司 自动光学检测设备的控制系统
US11449407B2 (en) 2020-05-28 2022-09-20 Bank Of America Corporation System and method for monitoring computing platform parameters and dynamically generating and deploying monitoring packages
CN111917513B (zh) * 2020-07-29 2022-11-22 上海海洋大学 一种移动端与服务器端数据交互方法
CN112306784A (zh) * 2020-10-29 2021-02-02 深圳宝新创科技股份有限公司 一种测试方法、装置、电子设备和测试系统
TWI811663B (zh) 2021-04-14 2023-08-11 國立臺灣大學 軟體測試報告產生方法及裝置
US20240288840A1 (en) * 2021-06-18 2024-08-29 Siemens Aktiengesellschaft Method and apparatus for coupling the functional control in a distributed automation system
IL311031A (en) 2021-08-31 2024-04-01 Nutcracker Therapeutics Inc A state machine based application and system for generating computer code snippets
CN115550336A (zh) * 2022-09-16 2022-12-30 宁夏隆基宁光仪表股份有限公司 一种基于Web的NB-IoT表计测试通讯方法、系统和测试设备
CN116501447B (zh) * 2023-06-20 2023-09-26 麒麟软件有限公司 基于Xen的硬实时实现系统

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5717614A (en) * 1994-05-04 1998-02-10 National Instruments Corporation System and method for handling events in an instrumentation system
US20020109722A1 (en) * 2000-12-20 2002-08-15 Rogers Steven W. System and method for performing type checking for hardware device nodes in a graphical program
US20020166000A1 (en) * 2001-03-22 2002-11-07 Markku Rossi Method for inverting program control flow
US6512988B1 (en) * 2000-05-25 2003-01-28 Agilent Technologies, Inc. Fast test application switching method and system
US20030056200A1 (en) * 2001-09-19 2003-03-20 Jun Li Runtime monitoring in component-based systems
US6587671B1 (en) * 1999-05-28 2003-07-01 Agilent Technologies, Inc. RF test set with concurrent measurement architecture
US6594612B2 (en) * 2000-12-11 2003-07-15 National Instruments Corporation Measurement system having an improved scan list configuration
US20040103391A1 (en) * 2002-11-27 2004-05-27 Gansha Wu Software object type identification apparatus and methods
US20040225465A1 (en) * 2003-02-14 2004-11-11 Advantest Corporation Method and apparatus for testing integrated circuits
US20060195744A1 (en) * 2005-02-11 2006-08-31 Broadcom Corporation Method and apparatus to simulate automatic test equipment
US20060241929A1 (en) * 2000-01-24 2006-10-26 Radioscape Limited Method of Designing, Modelling or Fabricating a Communications Baseband Stack
US7200529B2 (en) * 2003-08-15 2007-04-03 National Instruments Corporation Automatic configuration of function blocks in a signal analysis system
US20070124451A1 (en) * 2001-10-16 2007-05-31 Userspace Corporation Embedded system and method for controlling, monitoring of instruments or devices and processing their data via control and data protocols that can be combined or interchanged
US20070169042A1 (en) * 2005-11-07 2007-07-19 Janczewski Slawomir A Object-oriented, parallel language, method of programming and multi-processor computer

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1242486A (en) * 1983-11-25 1988-09-27 John J. Comfort Automatic test equipment
US5974241A (en) * 1997-06-17 1999-10-26 Lsi Logic Corporation Test bench interface generator for tester compatible simulations
US6405145B1 (en) * 1998-03-20 2002-06-11 National Instruments Corporation Instrumentation system and method which performs instrument interchangeability checking
US5963726A (en) * 1998-03-20 1999-10-05 National Instruments Corporation Instrumentation system and method including an improved driver software architecture
US6085156A (en) * 1998-03-20 2000-07-04 National Instruments Corporation Instrumentation system and method having instrument interchangeability
US6381735B1 (en) * 1998-10-02 2002-04-30 Microsoft Corporation Dynamic classification of sections of software
US6499137B1 (en) * 1998-10-02 2002-12-24 Microsoft Corporation Reversible load-time dynamic linking
US6631344B1 (en) * 1999-03-26 2003-10-07 Synopsys, Inc. Method and system for performing deterministic analysis and speculative analysis for more efficient automatic test pattern generation
US6563301B2 (en) * 2001-04-30 2003-05-13 Nokia Mobile Phones Ltd. Advanced production test method and apparatus for testing electronic devices
US6889118B2 (en) 2001-11-28 2005-05-03 Evolution Robotics, Inc. Hardware abstraction layer for a robot
CN100456043C (zh) 2003-02-14 2009-01-28 爱德万测试株式会社 检测集成电路的方法和装置
US8775997B2 (en) 2003-09-15 2014-07-08 Nvidia Corporation System and method for testing and configuring semiconductor functional circuits
US20050097548A1 (en) * 2003-10-31 2005-05-05 Dillenburg Brian J. Systems and methods for developing and distributing software components
US20050097515A1 (en) * 2003-10-31 2005-05-05 Honeywell International, Inc. Data empowered laborsaving test architecture
US7673197B2 (en) * 2003-11-20 2010-03-02 Practical Engineering Inc. Polymorphic automatic test systems and methods
US7149943B2 (en) * 2004-01-12 2006-12-12 Lucent Technologies Inc. System for flexible embedded Boundary Scan testing
US7222340B2 (en) * 2004-01-27 2007-05-22 Research In Motion Limited Software-delivered dynamic persistent data
US8418162B2 (en) * 2004-01-27 2013-04-09 Research In Motion Limited Network delivered dynamic persistent data
US7107173B2 (en) * 2004-02-03 2006-09-12 Credence Systems Corporation Automatic test equipment operating architecture
US7552024B2 (en) * 2004-03-08 2009-06-23 Kelbon Richard G Circuit board diagnostic operating center
US7210087B2 (en) * 2004-05-22 2007-04-24 Advantest America R&D Center, Inc. Method and system for simulating a modular test system
DE102006001776A1 (de) * 2005-01-12 2006-11-09 Advanced Testing Technologies, Inc. Testprogrammsatz Minimierung der Veralterung durch Software- und automatische Testgeräteprozesse
US8214800B2 (en) * 2005-03-02 2012-07-03 Advantest Corporation Compact representation of vendor hardware module revisions in an open architecture test system
US7418317B2 (en) 2005-03-10 2008-08-26 Aai Corporation System and method for controlling and communicating with a vehicle
US7958488B2 (en) * 2005-08-16 2011-06-07 National Instruments Corporation Virtual testing in a development environment
US20070294580A1 (en) 2006-05-31 2007-12-20 Ziyang Lu Virtual tester architecture
CN101512359A (zh) 2006-07-10 2009-08-19 阿斯特瑞昂公司 用于在测试系统中实施处理之系统及方法
JP4822346B2 (ja) * 2006-10-31 2011-11-24 アジレント・テクノロジーズ・インク 誘導結合プラズマ質量分析装置のための診断及び較正システム
US8356282B1 (en) * 2011-09-13 2013-01-15 Advanced Testing Technologies, Inc. Integrated development environment for the development of electronic signal testing strategies

Patent Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5717614A (en) * 1994-05-04 1998-02-10 National Instruments Corporation System and method for handling events in an instrumentation system
US6587671B1 (en) * 1999-05-28 2003-07-01 Agilent Technologies, Inc. RF test set with concurrent measurement architecture
US20090119088A1 (en) * 2000-01-24 2009-05-07 Radioscape Limited Method of Designing, Modelling or Fabricating a Communications Baseband Stack
US20060241929A1 (en) * 2000-01-24 2006-10-26 Radioscape Limited Method of Designing, Modelling or Fabricating a Communications Baseband Stack
US6512988B1 (en) * 2000-05-25 2003-01-28 Agilent Technologies, Inc. Fast test application switching method and system
US6594612B2 (en) * 2000-12-11 2003-07-15 National Instruments Corporation Measurement system having an improved scan list configuration
US20020109722A1 (en) * 2000-12-20 2002-08-15 Rogers Steven W. System and method for performing type checking for hardware device nodes in a graphical program
US20020166000A1 (en) * 2001-03-22 2002-11-07 Markku Rossi Method for inverting program control flow
US20030056200A1 (en) * 2001-09-19 2003-03-20 Jun Li Runtime monitoring in component-based systems
US20070124451A1 (en) * 2001-10-16 2007-05-31 Userspace Corporation Embedded system and method for controlling, monitoring of instruments or devices and processing their data via control and data protocols that can be combined or interchanged
US20040103391A1 (en) * 2002-11-27 2004-05-27 Gansha Wu Software object type identification apparatus and methods
US20040225465A1 (en) * 2003-02-14 2004-11-11 Advantest Corporation Method and apparatus for testing integrated circuits
US7200529B2 (en) * 2003-08-15 2007-04-03 National Instruments Corporation Automatic configuration of function blocks in a signal analysis system
US20060195744A1 (en) * 2005-02-11 2006-08-31 Broadcom Corporation Method and apparatus to simulate automatic test equipment
US20070169042A1 (en) * 2005-11-07 2007-07-19 Janczewski Slawomir A Object-oriented, parallel language, method of programming and multi-processor computer

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180307654A1 (en) * 2017-04-13 2018-10-25 Battelle Memorial Institute System and method for generating test vectors
US10789550B2 (en) * 2017-04-13 2020-09-29 Battelle Memorial Institute System and method for generating test vectors
US11120037B2 (en) 2019-06-21 2021-09-14 Wistron Corporation Test data integration system and method thereof

Also Published As

Publication number Publication date
US8442795B2 (en) 2013-05-14
US8065663B2 (en) 2011-11-22
US20160003892A1 (en) 2016-01-07
US20080021669A1 (en) 2008-01-24
KR20090082341A (ko) 2009-07-30
US20080040706A1 (en) 2008-02-14
TW200817931A (en) 2008-04-16
WO2008008773A1 (en) 2008-01-17
JP2009544012A (ja) 2009-12-10
US20080040641A1 (en) 2008-02-14
CN101512359A (zh) 2009-08-19
US20080040708A1 (en) 2008-02-14
US9032384B2 (en) 2015-05-12
US20080040709A1 (en) 2008-02-14
US7869986B2 (en) 2011-01-11
US7844412B2 (en) 2010-11-30

Similar Documents

Publication Publication Date Title
US8065663B2 (en) System and method for performing processing in a testing system
CN100580473C (zh) 支持开放架构测试系统中的校准和诊断
US6405145B1 (en) Instrumentation system and method which performs instrument interchangeability checking
US7809520B2 (en) Test equipment, method for loading test plan and program product
US20080320071A1 (en) Method, apparatus and program product for creating a test framework for testing operating system components in a cluster system
US20080016396A1 (en) Test emulator, test module emulator and record medium storing program therein
US20040255291A1 (en) Installing software using programmatic component dependency analysis
EP1610136B1 (en) Test emulator
US20150074653A1 (en) Executing code on a test instrument in response to an event
US7171587B2 (en) Automatic test system with easily modified software
JP2007057541A (ja) 試験エミュレート装置
US7149943B2 (en) System for flexible embedded Boundary Scan testing
US6895539B1 (en) Universal method and apparatus for controlling a functional test system
CN100456043C (zh) 检测集成电路的方法和装置
US7975198B2 (en) Test system and back annotation method
JP2005285092A (ja) 試験エミュレート装置
Mueller et al. Architecture drives test system standards
CN117785700A (zh) 一种实时操作系统第三方组件的测试方法、系统
Iman et al. e Reuse Methodology

Legal Events

Date Code Title Description
AS Assignment

Owner name: ASTERION, INC., MASSACHUSETTS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BLANCHA, BARRY E;LECHOWICZ, LESZEK JANUSZ;HELM, STEPHEN S;AND OTHERS;REEL/FRAME:020225/0326;SIGNING DATES FROM 20070910 TO 20071001

AS Assignment

Owner name: SHIBASOKU CO., LTD.,JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ASTERION, INC.;REEL/FRAME:024023/0596

Effective date: 20100304

Owner name: SHIBASOKU CO., LTD., JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ASTERION, INC.;REEL/FRAME:024023/0596

Effective date: 20100304

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE