TWI287639B - A distributed operating system for a semiconductor test system for testing at least one device under test - Google Patents

Abstract

A distributed operating system for a semiconductor test system, such as automated test equipment (ATE), is described. The operating system includes a host operating system for enabling control of one or more site controllers by a system controller. One or more local operating systems, each associated with a site controller, enable control of one or more test modules by an associated site controller. Each test module performs testing on a corresponding device-under-test at a test site.

Description

1287639 (1) 发明 发明 发明 发明 发明 发明 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本 本8 3 9 , "Method and Structure of Test Program for Volume Circuits"; 2003" 美国 US Application No. 1 0/404,002, "Testing Test Module Simulator, and Recording Media for Storage Programs": and The benefits of the US application No. 1/4 03, 817, preparation and test methods, filed on March 31, are incorporated in this document. The overall content of this application is intrusive. At the same time, the US application filed here _ "Method for developing a test program for a semiconductor integrated circuit and the application of the application claimed to be issued on February 14, 2003, E 6 0/44 7,8 3 9 "developing semiconductor The benefits of the test circuit and structure of the integrated circuit. BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to testing of integrated circuits (ICs) and is also used for testing automated test equipment (ATE) of one or more ICs. [Prior Art] Increasing complexity of system-on-a-chip (SOC) devices And the need to test costs at the same time has forced 1C manufacturers and tester sellers how to perform IC testing. According to industrial research, there is no application for the application of the ""2003 development semi-conducting ΐ March 31 simulator, 2003 "testing the installation system to cited by reference----number ^ structure", _ request The method of the first type is particularly relevant to the reduction of the wafer re-examination of the tester-5- (2) 1287639 The cost of redesigning the budget will continue to rise sharply in the near future. One of the main reasons for the high cost of test equipment is the proprietary nature of the conventional tester architecture. Each tester manufacturer has many tester platforms that are not only incompatible with companies, such as Advantest, Teradyne, and Agilent, but are also incompatible across platforms, such as by

T3 3 0 0, T5 5 00 and T6600 series testers made by Advantest. Based on these incompatibilities, each tester needs its own dedicated hardware and software components that cannot be used in other testers. In addition, a major translation effort is required to port a test program from one tester to another' and the second solution is difficult to develop. Even when a third party solution has been developed for a platform, it cannot be ported or reused on a different platform. The translation process from one platform to another is generally complex and error-prone, resulting in additional effort, time and increased testing costs. One of the main reasons for measuring the cost of an S-type device is the proprietary nature of the conventional tester architecture. Each tester manufacturer has a number of tester chambers, which are not only incompatible with companies, such as Advantest, Teradyne and AgUent, but also cross-platforms made by the same company. Ding 33〇〇, Ding 55〇〇 and Τ6600 series testers made by Advantest. Based on these incompatibilities, each tester needs its own dedicated hardware and software components that cannot be used in other testers. In addition, a major translation effort is required to migrate a test program from one tester to another, and the third party's solution is difficult to develop. Even when a third party solution has been developed for a platform, its -6-(3) 1287639 cannot be ported or reused on a different platform. Translation processing from one platform to another is generally complex and error-prone, resulting in additional effort, time, and increased testing costs. Run tester software such as operating systems and test analysis tools/applications on a host computer. Based on the proprietary nature of the architecture, all hardware and software remain in a fixed architecture for a given tester. To test an IC, develop a dedicated test program that uses some or all of the capabilities of the tester to define the test data, signals, waveforms, and current and voltage levels, and to collect the DUT response and Determine the DUT pass/fail. Because a tester should be able to test a wide range of I C s , both hardware and software components are designed to operate over a wide operating range. As such, a tester contains many resources that are not used in many test states. At the same time, for a given 1C, the tester cannot provide the most desirable resources for the IC. For example, it is suitable for testing a complex embedded microcontroller, large embedded dynamic random access memory (D RAM) and flash memory, and various peripheral interface (PCI) and universal serial bus (USB). Other core SoC A logic testers may find it inappropriate to use an embedded microcontroller and large embedded DRAM/flash memory, but include digital analog converters (DACs) and integral triangles. (Sigma-Delta) converter ASIC B. To test ASIC B, an appropriate tester would require an analog and mixed-signal test unit rather than extensive support for embedded memory testing. Therefore, what it wants is to provide a δ-style hack that can be re-arranged according to the test requirements -7- 1287639 (4). In addition, what it wants is to connect and use the relevant seller equipment. However, based on the proprietary nature of the prior art test system and the data format in each vendor device, it is possible to plug in and use equipment from another vendor. SUMMARY OF THE INVENTION V An open architecture of one embodiment of the present invention allows the use of a third party module. The hardware of the test system includes a standard interface' and the modules from different vendors can interact with the interface. The module can be a hardware, a unit, a digital pin card, an analog card, or a device power supply; or a tool or utility, including a test execution tool monitoring or approval tool, a unit level controller (eg, an instrument, Universal interface bus - G Ρ I Β control), database, software for controlling the device. In one embodiment, the architecture is a decentralized object environment under Microsoft Visualization. The tester is a modular system with a module control software communication library to module communication and controller to module communication. The module is, for example, a packet group, a device power supply (DPS) module, an arbitrary waveform generator (group, a tablet module, and a specific application software. In one embodiment, a module connection enabler package and multiple module connections) Switching matrix network of synchronous mechanism. When most DUTs are styled, the switch matrix network is also used in most I and ATEs. It usually does not test the system and the software is mainly plugged in, such as functional software, programs, systems. For example, the basic or for the window operation allows the module body and a back digital analog AWG) module to provide a test for sharing the same controller and (5) 1287639 test locations to allow sharing of common test data and resources. Because of the independent location controller for each location, all test locations can operate asynchronously. This actually helps most DUT tests. The modular and complex position structure also provides scalability to the system. In one embodiment of the system, the ability to structure a single controller to control and test most DUTs, plug-and-play or replaceable modules is at the hardware and software level through the use of standard interfaces. It's easy. In software, frame classes are often able to act, control, and monitor the module. The framework is a group of categories and methods for performing common test-related operations. This includes categories for power and pin electronic sequencing, setting current/voltage levels and timing states, obtaining measurement results, controlling test flow, and more. The framework also provides methods for sub-program services and debugging. The frame article can operate via a standard interface in accordance with an embodiment of the present invention. Provide a C++-based reference implementation of one of the framework categories. A user can also develop a specific framework category of his or her own. Get a hardware-software interface and communication through a backplane communication library. The open backplane communication library via the C++ language-based test program and the graphical user interface (GUI) test program access layer in C++ provides generalization for the test system. user interface. The method of constructing a test program using C/C++ construction is disclosed in U.S. Application Serial No. 60/44 7,83,9. The communication library provides communication with the address controller in a manner that is succinct to the user application and test program. Essentially, the backplane communication library is intended to be used across the test -9- 1287639 (6) tester backplane (on this point, the "backplane" is an abstraction that does not have to be a physical hardback Board) Communication interface to provide the functional program required to communicate with the module connected to the special address. The use of this library exempts the model vendor from creating its own driver (such as the Microsoft Windows driver). This allows the vendor specific module software to use the standard backplane driver to communicate with the corresponding hardware module. In a specific embodiment, the backplane protocol uses a packet-based format. One of the advantages of an open architecture is that it simplifies the entire tester approach. It provides a mechanism to develop third-party solutions and reuse these solutions without significant redoing. For any given test address', the appropriate module can be selected and used as intended. Because the modules are replaceable, each test address can be re-architected to achieve a DUT's best test SS; It also simplifies cross-platform incompatibility issues. All of these simplifications result in reduced effort, faster read and write conversion times, and subsequent reduced test costs. The present invention provides a system for testing at least a device under test (D UT ). The system includes at least one address controller for controlling one less test module to apply at least one test (possibly a portion of the test plan) to at least one D U T . A system controller controls the at least ~ address controller. A test module interface defines a test module function for acting as an interface between the ~& address controller and the first test module, wherein the test module interface can be extended to serve as the address controller to the second The interface of the test module, the interface of the unextended test module is not sufficient to serve as the interface between the address controller and the first 10-10287639 (7) test module. The system includes an extendable test function, such as a test level that can be defined by the user, regardless of the DUT characteristics. One test is the implementation of the extendable test function. A test module can communicate with the DUT using a tester pin interface that is independent of the DUT characteristics. The test module interface can include a test module interface category, and the tester pin interface can include a tester pin interface category. A decentralized operating system according to an embodiment of the present invention includes at least a main operating system for controlling at least one address controller by a system controller; and at least a partial operating system, each address The controllers are connected to enable control of at least one test module by a connected address controller. At least one test module is tested on a corresponding DUT. The primary operating system can synchronously operate the at least one address controller, the mediation communication between the system controller and the at least one address controller, and the monitoring operation of the at least one address controller. An address controller can monitor the operation of at least one test module coupled to the address controller. The primary operating system includes at least one host interface for communicating with the at least one address controller. A test module interface defines a test module function for acting as an interface between the address controller and the first test module, wherein the test module interface can be extended to serve as the address controller to the second test The interface of the module, the interface of the unextended test module is not sufficient as the interface between the address controller and the second test module. -11 - 1287639 (δ) The main operating system can contain at least one main frame category, developed in a standard computer language (eg C/C++), so that users can develop specific categories of applications to control the To the controller. Each partial operating system can include at least one partial framework that can be developed in a standard computer language (e.g., C/C++) to allow a user to develop a particular type of application for controlling a test module. By the number of modules controlled by each address controller. The local operating system architecture associated with a corresponding address controller is capable of making the address controlled by the system t controller variable by the test module style system controlled by the address controller, and The number of statics measured by the test system can be varied. A simulator can simulate a candidate test method with the test system to confirm that the candidate module is compatible with the test system. [Embodiment] FIG. 1 illustrates a generalized architecture of a conventional tester, how a signal system is generated and applied to a test object (D U T ). The i input pin is connected to a driver for application test data. 2 The DUT output pin is connected to a comparator 4. Most use a tri-state driver-comparator so that each tester pin can act as an ~input pin or as an output pin. It can be used to make one address less than one address, so that it can be changed at least. The number of master controllers: the DUTs module uses it to display a 5-DUT, and in each case, the (channel) test pins for a single -12-(9) 1287639 DUT collectively form a test bit. And associated with the work, a timing generator 6, a waveform generator 8, an image memory 10, a timing data memory 1, a waveform memory data 14, and a component 16 defining the data flow rate. Figure 2 illustrates a system architecture 1 根据 in accordance with an embodiment of the present invention. A system controller (SysC) 1 〇 2 is coupled to a complex address controller (SiteCs) 104. The system controller can also be coupled to a network to access related files. Each of the address controllers is coupled to one or more test modules 108 at a test address 1 1 经过 via a module connection enabler 106. The module connection enabler 1 〇 6 allows the re-architecting of the connected hardware module 1 () 8 and also serves as a bus for data transfer (for loading pattern data, collecting reaction data, providing Control, etc.). In addition, after the module is connected to the enabler, the module at one address can access the module at another address. The module connection enabler 106 allows different test addresses to have the same or different module architectures. In other words, different numbers and styles of modules can be used for each test address. Possible hardware implementations include dedicated connections, switch connections, bus connections, ring connections, and star connections. The module connection energizer 1 〇 6 can be implemented, for example, as a switch matrix. Each test address 1 1 0 is associated with a DUT 1 1 2, which is connected to the module of the corresponding address via a load board U 4 . In one embodiment, a single address controller can be connected to a plurality of DUT addresses. The system controller 102 serves as the entire system manager. It coordinates the address controller activity, manages the system level parallel test strategy, and provides information processing program/probe control and system level data login -13-1287639 (10) and error handling support. Depending on the operational settings, the system controller 102 can be deployed on a central processing unit (CPU) separated by the operation of the address controller 1 〇 4. Another option is that a shared CPU can be shared by the system controller 102 and the address controller 1 〇 4. Similarly, each address controller 104 can be deployed on its own dedicated CPu (Central Processing Unit) or separate processes or threads for one of the same CPUs. The system architecture may be imagining the decentralized system shown in Figure 2, and understand that the individual system components can also be considered as a logical component of a single system, and do not need to be considered a decentralized system. Physical components. Figure 3 illustrates a software architecture 2根据 in accordance with the present invention. The software architecture 200 represents a decentralized operating system having communication with associated hardware system components 102, 104, 108 for the system controller 220, at least one address controller 240, and at least one mode The components of group 260. In addition to the module 260, the architecture 200 includes a corresponding component for the module emulation of the software in the software. As a demonstration option, the development environment for this platform can be based on Microsoft Windows software. The use of this architecture has the added benefit of program and support portability (e.g., a field maintenance engineer can connect a laptop computer to run the tester operating system to perform advanced diagnostics). However, for large computationally intensive operations (such as test pattern compilation), the software can be created as a separate entity that can operate independently to allow for work scheduling across distributed platforms. Related to batch work -14- (11) 1287639 Software tools are so capable of obscuring in multiple platform styles. As an alternative, the ANSI/ISO standard C++ can be used as the original language for the software. Of course, there are multiple options available (to provide a layer above the nominal C++ interface), while allowing a third party to integrate into the system in another language of its own choice. Figure 3 illustrates their shadow changes by means of a nominal source (or collectively developed into a subsystem) that includes the tester operating system interface 290 and user components 292 (eg, for testing purposes) Provided by the system, system components 2 9 4 (for example, for basic connection and communication supply as a software lower mechanism), module development component 296 (for example, supplied by a module developer), and external zero Component 2 98 (for example, by the source of the module developer, the source is supplied). From a source-based organizational perspective, the Tester Operating System (TOS) interface 290 includes: a system controller to address controller interface 222, a framework category 224, an address controller to a module interface 24 5, a framework category 246 , scheduled module level interface, backplane communication library 249, chassis slot IF (interface) 262, load board hardware IF 264, backplane analog IF 283 load board analog IF 285, DUT analog IF 287, for DUT's Verilog model's Verilog PLI (programming language interface) 2 8 8 and C/C++ language support for DUT's C/C++ model 289. User component 2 92 includes: a user test plan file 242, a user test category 243, a hardware load board 265, and a DUT 266, a DUT Verilog model 2 93, and a DUT C/C++ model 291. System component 294 includes: system tool 22 6. communication library -15- (12) 1287639 23 0, test category 244, backplane driver 205, HW backplane 261, analog frame 28 1, backplane simulation 2 8 2 'and load board simulation 2 8 6. The module development component 296 includes: a module command implementation 24 8 , a module hardware 2 6 3 , and a module simulation 284 . The external component 2 9 8 includes an external tool 22 5 . The system controller 220 includes an interface 222 to the address controller, a framework category 224, a system tool 226, an external tool 225, and a communication library 230. The system controller soft system is the primary interaction point for the user. It provides a gateway to the address controller of the present invention and the synchronization of the address controller in a multi-address/DUT environment, as described in U.S. Patent Application Serial No. 60/449,622. The person described in the article. User applications and tools, based on a graphical user interface (GUI) or otherwise running on the system controller. The system controller can also be used as a solution. There is a data repository for information about the test plan file, which contains test plan files, test styles, and test parameter files. In the object oriented environment of a particular embodiment of the invention, a test parameter file contains parameterized data for a test category. The third developer can provide tools in addition to (or in place of) the standard system tool 226. The standard interface 222 on the system controller 220 includes an interface for accessing the tester and test objects using the tool. The tool (application) 22 5, 226 allows conversational and batch control of the test and tester objects. The tool includes an application for providing automation capabilities (eg, via SECS/TSEM, etc.) The communication library resident on the system controller 220 provides the-16-1287639 (13) mechanism for use. Concise user application and static measurement of the address controller 240 communication. Remaining in connection with the system controller 2 2 0 2 2 2 provides an open interface to the frame object, which is executed on the object. The included person is the interface that allows the software to access and retrieve the pattern data by the address control group. The program and tools are also used to access the tester and test object scripting interface. The scripting interface provides a capability program engine to access and process the tester and test zero sets for conversational, batch and remote applications. Share tb. The framework category associated with the system controller 220 interacts with these aforementioned objects and provides a reference implementation. For example, the address controller of the present invention can test objects. The system controller framework category is a functional test agent host and serves as a controller-based alternative to the functional test system. Such a test interface is made available to the system controller 220 system, module-development, and interface components 2 94, 296 considering a dispersion of the system controller and the address control system. The framework category effectively provides an interface to the main system operating system. They also constitute the software component, and the address controller provides synchronization of the gateway and the address controller provided in the multi-> environment. In this way, the way of the program and the interface in the memory is based on the control of the system. The user uses the interface and the script. This allows a mechanism to perform its functions. 224 provides a machine for a standard interface 240 to provide a function of providing one of the corresponding test objects far beyond the standard functional tool. The software component pair address/DU butyl ring connected to the operating system controller of the 190 is provided in the object model of the present invention -17-(14) 1287639, which is suitable for processing And access to the address controller without having to deal directly with the communication layer. The address controller 240 stores a user test plan file 242, a user test category 24 3, a standard test category 244, a standard interface 245, an address controller frame category 246, and a module high-level command interface (ie, a predetermined module). Hierarchy interface) 24 7. Module command implementation 24 8. Backplane communication library 249 and a backplane driver 2 50. Preferably, most of the test functionality is handled by the address controller 104/240, thus allowing independent operation of the test address 1 1 . A test plan file 242 is written by the user. The program file § is written directly by the S standard computer such as C++ or in a more general test program programming language: to generate C++ code, then the C++ code can be compiled into Execution test program. The test plan file establishes a test object by using the framework category 246 and/or standards or a user-supplied test category 244 associated with the address controller, constructs the hardware using the standard interface, and defines The test plan file process. It also provides any additional logic required during the execution of the test plan file. The test plan file supports some basic services and provides an interface to services such as debug services (such as breakpoints) for the following items, and access to the following frameworks and standard categories. The framework category 2 4 6 associated with the address controller is a set of categories and methods for performing common test related operations. The address controller hierarchy includes categories for power and pin electronic sequencing, setting levels and timing states, obtaining measurement results, controlling test flows, and the like. The framework also provides a method for sub-program services and debugging. -18- (15) 1287639. The frame object can work through the implementation of the standard interface. For example, the test pin frame type is standardized to implement a general tester pin interface, and its test category can be used to interact with hardware module pins. A frame object can be provided to work with the help of the module hierarchy interface to communicate with the module. The address controller framework category is effectively used as a local operating system interface to support each address controller. Generally, more than 90% of the code is used for testing the device, and the remaining 10% of the code implements the test methodology. The device test data is based on the DUT (eg power status, signal voltage status, timing status, etc.). The test code includes the method of loading the specified device state onto the ATE hardware, and also includes methods that require user fingerprinting (such as data posting). The framework of one embodiment of the present invention provides a hardware-dependent test and tester object model that allows the user to perform DUT test program planning. To increase the reusability of the test code, this code can be used to identify any device-specific data (such as pin names, analog data, etc.), or device test specific data (such as for DC units, measuring pins, target pin count, style files). The name, the state of the style program is not relevant. If the test code is compiled with these styles, the reusability of the test code will be reduced. Thus, in accordance with an embodiment of the present invention, any device specific material or device test specific data may be externally made valid for the test code during code execution as an input. In a specific embodiment of the present invention, for a special style test - 19- (16) 1287639 test 'a standard test interface implementation test category, here ITe st implementation test data and code (and therefore Separation of code reuse). This test category itself can be considered as a "template" for separate illustrations that differ only from one another based on device specificity and/or device specific data. Specify the test category in the test plan file. Each test category typically provides one of the specific styles of the test or the settings used for the device test. For example, one embodiment of the present invention may provide a specific implementation of the ITe st interface, such as FunctionalTest, as a basic category for functional testing of all DUTs. It provides a set test state, an execution pattern, & determines the test pattern based on the presence of the fault strobe pulse. The basic function of the state. Other styles of implementation may include AC and DC test categories, labeled ACParametricTests and DCParametricTests. 〇 All test patterns provide predefined implementations of virtual methods such as init (), preEXeC ( ) 5 and postExec (). These methods become the entry point for the test engineer to override the predetermined behavior and set any test specific parameters. However, custom test categories can also be used in test plan files. The test category allows the user to provide a class structure class behavior by specifying options for the particular example of the test. For example, a functional test may take the parameters P L丨s t and T e s t C ο n d i t i ο n s to specify a list of styles to be executed, and the level and timing state for the test. Different assignments to these parameters (via the use of different "test" blocks in the test plan narrative) allow the user to establish different instances of a functional test. Figure 4 illustrates how different test cases can be derived from a single test -20- (17) 1287639 category. A type library library can use a general purpose library that acts as a general algorithm and data structure. The user of the tester can see the library so that the user can modify the implementation of a test category to establish a user-defined test category. As regards the test categories developed by the user, a specific embodiment of the system supports integration of the test category into the framework, wherein all test categories are derived from a single test interface, such as ITest, so that the framework can be the same as the standard test group of the system test category. The way they are handled. Users are free to put additional functionality into their test categories and understand that they must use custom code in their test programs to take advantage of these additional devices. Each test address 1 1 is dedicated to testing one or more DUTs 106, and works through one of the test modules 1 1 2 to construct a collection object. Each test module 1 1 2 is an entity that performs a special test work. For example, a test module 1 12 can be a DUT power supply, a pin card, a type of card, and the like. This modular approach provides a high degree of flexibility and architecture. The module command implementation category 24 8 can be provided by the module hardware vendor and can be supplied to any module level interface of the hardware module or provided by the vendor according to the command implementation method selected by the seller. Module-specific implementation of the interface. The external interfaces of these categories are defined by the requirements of the predetermined module level interface and the requirements of the backplane communication library. This layer also provides an extension of the standard settings for test commands, allowing for the addition of methods (functions) and data elements. The backplane communication library 249 provides a standard communication interface for the backplane to provide the functionality required to communicate with the module connected to the test location - 21 - (18) 1287639. This allows the vendor specific module software to use a backplane driver 250 to communicate with the corresponding hardware module. The backplane communication protocol can use a basic format of the package. The tester pin object represents the physical tester channel and is derived from a tester pin interface, labeled ITseterPin. The Software Development Kit (SDK) of the specific embodiment of the present invention provides a predetermined implementation of ITseterPin, which may be referred to as TseterPin, and is supplied from the perspective of a predetermined module hierarchy interface, IChannel. Sellers are free to use TseterPin if they can provide the functionality of their modules from IChaiinel's point of view; otherwise, they must provide one of ITseterPin's implementations to work with their modules. The standard module interface provided by the tester system of the present invention and labeled I Μ u u 1 e generally represents a vendor's hardware module. Seller-supplied module-specific software for the system, such as Dynamic Linked Libraries (DDLs), can be provided in an executable form. The software from the vendor for each module type can be embedded in a single DLL. Each of the software modules is responsible for providing vendor specific implementations for the module interface commands, including APIs for modular software development. There are two arguments for the module interface command: first, they serve as the interface for the user to communicate (indirectly) with a particular hardware module in the system; and second, they provide the third-party developer Can be used to integrate its own modules into the interface of the address controller hierarchy. Thus, the module interface commands provided by the framework are divided into two types: The first and most obvious are those that are exposed through the framework interface to the user of the -22- 1287639 (19). Thus, the tester pin interface (ITseterPin) provides a means to obtain and set the level and timing, and a power interface (IPowerSupply) provides, for example, a method for powering up and shutting down. In addition, the framework provides a special paradigm for the predetermined module hierarchy interface that can be used to communicate with the module. These are the interfaces used by the framework categories (i.e., the "standard" implementation of the framework interface) to communicate with the vendor model. However, the use of this second argument, the module hierarchy interface is selected. The advantage of this is that the seller can then use the implementation of the categories, such as ITseterPin and IPowerSupply, by focusing on the content of the specific message sent to the hardware by the module level interface. . However, if these are not appropriate for the seller, they may be selected to provide a self-determined implementation of their framework (eg, vendor implementations of ITseterPin, IPowerSupply, etc.). These will then provide the appropriate custom functionality for their hardware. The integration of the module-specific vendor software can be achieved in two different ways: the self-determined implementation of the relevant framework categories and interfaces, or the self-defined implementation of the special scope of the module hierarchy. Next, an example application of the two methods is presented by the assistance of Fig. 5, which is a system language (U M L ) category diagram, and describes the interaction between the tester system of the present invention and the vendor supply module. The seller of the new digital module, the third party A (ΤΡΑ), provides a software module 'to communicate with its hardware module. This software module will be supplied to the standard interface 'IModule. Let the module object be called TPAPinModu]e. The -23-(20) 1287639 square TPA can be implemented using the standard system of the ITseterPin interface, labeled TseterPin, by supplying the relevant predetermined module-level interface - in this case, Ichann el - In its module. This may be caused by the fact that the TseterPin uses a standard predetermined module level interface, such as Ichannel, to communicate with the module. Therefore, TP APinModule provides stitching by simply creating and exposing TseterPin objects. Now consider a different vendor, Third Party B (TPB), which decides that the Ichannel interface will not work well with its hardware. Therefore, TPB does not only need to provide its own IModule implementation (TPBPinModule), but also provides one of the ITseterPin interfaces, TPBTseterPin. This approach gives third developers a lot of flexibility to choose how to develop their hardware and support software. Although they need to supply the IModule interface, they can be selected to supply module level interfaces or to supply objects like TseterPins, as they are known to be suitable. In fact, the seller can choose to supply TseterPins to provide an extension that is not supported in the ITs eter Pin interface. The framework will provide a user-based mechanism for retrieving a specific interface or an indicator of the implementation of an object. This means that when the user code has an ITs eter Pin indicator, the framework will be able to determine if it is pointing, that is, a P B T s e t e r P i η object, if it is needed. (Note that this feature is available via standard C++ Execution Type Identification (RTTI)). In other words, when the test plan file calls the ϊ T seter P i η interface, the interface can directly request the vendor tester pin implementation of the TseterPin category, which is a combination of module specific -24- (21) 1287639 Information (such as the address of the register to be set to provide a special DUT simulation). In short, although the framework code will always use the ITseterPin interface, the user is free to utilize the specific components and extensions provided by the module vendor, if desired. In other words, a module seller can, for example, add methods (functions) to the standard system implementation of the category. For the user's transaction, the specific vendor extension is used to make the test code less usable with other vendors' modules. At the module level, the system 100 has a nominal two operational model. In the on-line operation model, a module component 260 (e.g., a hardware component) is used, and in a disconnection operation model, a modular simulation in software 2000 is used. For the online operation model, the module component 260 includes an HW (hardware) backplane 261, a chassis slot IF (interface) 2 62, a module hardware 263, a load board hardware if 264, and a hardware load board 2 65. And DUT 266 〇 For the disconnection operation model, the module simulation in the software 280 includes a simulation frame 281, backplane simulation 2 8 2, backplane simulation if 2 8 3, module simulation 284, load board simulation IF 2 8 5. Load board simulation 286, and DUT analog IF 28 7. The second model is shown for DUT simulation. A model using Verilog includes the Verilog PLI (Programming Language Interface) 2 8 8 and a DUT Verilog Model 293. A model using C/C++ includes C/C++ language support 2 8 9 and a DUT C/C++ model 291. Note that the simulation can be performed on any computer, such as a personal computer. - 25- (22) 1287639 In this online model, the module vendor provides physical hardware components to support testing, such as digital tester channels, DUT power supplies, or DC measurement units. The module forms an interface with the HW backplane 261 through the chassis slot IF 2 62. In addition, for disconnection work, another environment based on the PC or the equivalent device running the system controller will assume all the sub-program environment providing the address controller hierarchy framework and the lower layer of the software, and the simulation hard The responsibility of the body. The backplane simulation 2 8 2 provides a software replacement for the physical backplane 261. This communicates with the (provided by) module emulation software 2 84 via the backplane analog interface 283.

The module emulation software 2 84 is preferably provided by the vendor of the module and is typically closely coupled to a special vendor of a module 263. Thus, the module emulation software will typically differ in the details across the modules supplied by different vendors. In this case, the module simulation allows the seller to expose hardware functionality via a software model (eg, the module emulation software 2 84 ), send analog signals to the simulated load board 2 86, and receive and process from the The DUT response signal of the load board 28 is simulated and connected to the software 29, 2 93 forming the DUT model via the DUT analog IF 287. In some cases, the seller may find it advantageous to provide a simple functional simulation of the module's firmware and bypass simulation. The module simulation software compares the response of the analog DUT to the analog signal of the analog module with a well-known DUT reaction. Based on this comparison, the software decides whether to perform the test by the module, if it wants to achieve its target of testing the DUT -26 - (23) 1287639, and one of the physical testers on the line 1C (physical DUT) ) Help the user debug the module before using it. The load board analog interface 285 has a line tube function for routing signals to and from the module analog layer and the simulated load board 286. The load board analog component 286 supports device pin conversion and signal propagation to and from the DUT analog IF 2 8 7. The DUT simulation can be a native code (i.e., C/C++) simulation 291, or a Verilog programming language interface (PL) of a functional model of the target device 2 93 to be tested. The model forms an interface with the simulated load board through the DUT analog interface 287. Note that the overall control of these layers is provided by the simulation framework 281. The simulation framework measures the response of the analog DUT to a conventional analog signal. The method of system simulation is disclosed in U.S. Patent Application Serial No. 10/403,817. Communication and Control Communication and control are carried out through the management of related software objects. Preferably, a communication mechanism is hidden behind one of the object models on the system controller. The object model provides a proxy host for the categories and objects found by the address controller and thereby provides a convenient programming model for application development (e.g., 1C device testing). This allows the application developer (e.g., the user of the ATE system) to avoid unnecessary details regarding the communication characteristics between the application and the address/system controller. -27 - (24) 1287639 Figure 6 illustrates a particular embodiment of an address controller object, as maintained by address controller 104 in the address controller software 240. The address controller object includes CmdDispatcher 602, FunctionalTestMsgHandler 60 4, and FunctionalTest 606. The interface includes IMsgHandler 608 and ITest 610. The address controller software 240 preferably includes all of the functional categories that an application access may need. These categories can include, for example, tests, modules, pins, and the like. Since the user's test and software tools are typically resident on different computers, the message will be sent by the tool on the system controller to one of the servers on the address controller. This server will call one of the methods on the command delivery object. The command delivery object (CmdDispatcher) 602 maintains an image of the message handler object and provides the IMsgHandler interface 608. Figure 6 illustrates one specific implementation of IMsgHandler, FunctionalTestMsgHandler 6 0 4 . The information received by the CmdDispatcher object 602 contains an identification word for the object to be communicated. This identification word is found in an internal image and broken down into that particular implementation, which is shown in this case as a FunctionalTestMsgHandler object 604. In this example, IMsgHandler 60 8 includes a single method, H a n d 1 e M e s s a g e (). This method is best implemented as a single implementation category. In the case shown, the FunctionalTestMsgHandler 604 will send a message on one of the six methods depending on the exact nature of the incoming message. The header of the incoming message contains a message i d that allows the message handler to decide how to translate and where to send the message. -28- 1287639 (25) The corresponding communication environment of the system controller I 02 is related to the tools 22 5, 226 of the system controller software 220. Figure 7 illustrates a specific embodiment of a tool object (or system controller object) maintained on system controller 102 in system controller software 220 and corresponding to the address controller object of Figure 6. The tool object includes an object CmdDispatcher 702, FunctionalTestMsgHandler 704, and

FunctionalTestProxy 706. The interface includes IMsgHandler 708, ITestClie n 710, and IDispatch 712. Also included is a utility application 7 1 4 . For this example, the classes S!j CmdDispatcher 702, IMsgHandler 708, and FunctionalTestMsgHandler 704 are the same as those of Figure 6. However, specialization of F u n c t i ο n a 1 T e s t 6 0 6 (or any other address controller class) is not used. Conversely, the tool object has a proxy host class for communicating with each object on the address controller 1 〇 4. So, for example, the tool object contains a functional FunctionalProxy 706 that replaces FunctionalTest 6 0 6 . Similarly, the ITestCIient 710 in the tool object is not the same as the ITest 61 0 in the address controller object. In general, an application executing on the system controller 102 will not use the actual interface as provided on the address controller 104. In this case, the ITest 6]0 method (ie, preExec ( ), execute (), and postExec ()) is replaced by the single method ITest Client 710 (that is, runTe st ()). In addition, ITestCIient 7]0 is preferably a dual interface; that is, it inherits from ID i s p a t c h 7 ] 2, which is supplied as a Microsoft component object model -29-(26) 1287639 (C〇M). It provides an interface that enables the scripting engine to access the objects that supply the interface. This allows the system to rewrite scripts on the Microsoft Windows platform. As an example of the operation of the specific embodiment shown in FIG. 6-7, an application executed on the system controller 102 (for example, in one of the tools 2 2 6, 2 2 8) can be combined with an application. The address controller 1 通讯 4 communicates, where a test plan file 242 includes one or more Function alTe st objects 606. During the initialization of the test plan file 242 on the address controller 104, a corresponding test plan object is loaded onto the address controller 104, and a TestplanMessageHandler object is constructed and the CmdDispatcher object is used. The object is logged in. This assigns a unique ID to the message handler. A similar operation occurs with other TestP lan objects that make up the test plan file 242. The application on the system controller 1 ( 3 (e.g., in tools 226, 228) initializes the communication library 230, connects to the address controller 104 via a communication channel, and obtains an ID for the TestPUn. The library constructs a TestPlanProxy object and initializes it with this ID. During initialization, this proxy host object determines how many tests it contains and its type and ID s. It loads the appropriate DLLs for each type (only one pattern in this case) and constructs the proxy host objects for them, and initializes them with their IDs. The test agent host object is also initialized in sequence. To do so, they construct the appropriate message to get their name (using their ID 値) and send them to a communication server at the address controller I 〇 4, and the message -30-(27) 1287639 The information is sent to the C md D ispatcher 6 0 2. The object searches for the destination IDs in its internal image and advances the message to the handleMessage() method of the FunctionalTestMsgHandler object 604. For example, if the message is a request for a test name, the object obtains its individual test name and responds to the test agent host object of the application with the appropriate name string. After the initialization, the application has remote access to a TestPlan object and there are two test objects through the application. The user can now depress one of the "Run Test Plan" buttons on the application. As a result, the application calls the R u η T e s t p 1 a η () method on the host object of the test plan file. This method constructs a RunTestPlan message with the destination ID of the purpose test plan object, and calls the sen dMes sage () function on the RPC proxy host, and sends the message to the address controller. The communication server on the address controller 104 calls the handleMessage() method on the CmdDispatcher object 602 and passes the ID of the test plan object. The CmdDispatcher object 602 searches the internal image for the ID, finds the message handler for the TestPlan object, and calls the hand 1 e M essage () method on the object, which sequentially calls the RunTestPlan on the TestPlan object ( )method. In a similar manner, the application can obtain the name and final operational status of the test object. Method of using the communication library -31 - 1287639 (28) The following is an example of using the communication library 260. The communication library 2 3 0 is preferably a static library. An application can use this communication library via a Co mm Library .h file. An application that needs to output the communication library class should have a handler definition C〇MMLIBRARY_EXPORTS , COMMLIBRARY_ FORCE — LINKAGE defined in addition to the files contained above. An application that enters the communication library does not need to define any preprocessor definitions. When the communication library is used as a server, the application must call CcmdDispatchei's following static function: initializeServerunsigned long portNo) ° The portNo should be listening to the server's portNo. The command dispatcher corresponding to the server can be retrieved by calling the static function program: getServerCmdDispatcher on the CC md D ispatche 1 class SU. When the communication library is used as a client, the application The following static function program will be called CcmdDispatcher: initializeClientconst OFCString server Address » unsigned long serverPortNo, CcmdDispatcher**pCmdDlspatcher, OFCString serverld) The serverAddress and ServerPortNo of this client must be connected. This function initializes the command dispatcher metric for the client and its connected serverld. Also at a later point in time, the client can retrieve the command dispatcher corresponding to the serverld by calling the static function program getClientCmdDispatcher -32- (29) 1287639. When compiling the communication library, the constructor has been excluded from the files Clientlnterface.idl and Serverlnterface.idl. The preferred embodiment applies the stub module and the proxy host file that have been generated and used for the interface definition files to link the proxy host and the stub module implementation file into the same library. Therefore, the server and client can be instantiated in the same addressing space. Preferably, the following changes in the interface definition file and the stub module file are caused so that the communication library works as the server and client in the same addressing space. Changes in the interface definition file The following namespace declarations are best added to each interface definition file. This is to avoid name conflicts between the proxy host implementation function program and the implementation of the interface function itself. The following namespace declaration is added to the serverlnterface.idl: cpp_quote ("#ifdef-cplusplus") CPP — quote ( “namespace COMM_SERVER”) cpp —quote ( cpp_quo te ( “ #endif”) cpp —quote (change this The stub module implements a function program in the archive to call our own implementation function program for the function program declared in the interface, that is, we have a different name corresponding to each function program declared in the interface. The function program. -33- (30) 1287639 In order to avoid conflicts in the function program call, it is preferable to use the "COMM_" string as the prefix of the name of the implementation function program. Therefore, the stub module function program The code in the middle is changed to call "C 〇Μ Μ _ functi ο η N ame " instead of " fu 11 c ti ο η N ame . For this working method, all existing functional categories should also have their corresponding message handler objects. And the proxy host category. All message handler objects should be free from the IMsgHandler class provided by the communication library. The IMsgHandler category is one. The category of abstraction. It is best responsible for the implementation of the message handler to provide a definition for the handleMessage, setObjectld, handleError. All messages should be started by - (we retain zero as hand leErr or ). The category preferably has its corresponding message handler as its component variable. In the functional category of the constructor, the functional category will be logged in by calling a function program provided by its message handler. The message processing program itself. The next message handler object should be logged in by the command dispatcher by calling the addMsgHandler function program on the command dispatcher, which has the message handler as the parameter. The addMsgHandler function The program will assign an ID to the message handler and the functional category. The broken program of the functional category will call the rem 〇ve M sg H on the command scheduler by sending the functional category identifier as a parameter. And 1 er function program. The proxy host category will also follow the same login procedure. . The description of the functionality of the categories displayed in the category CTestPlan particularly preferred embodiment of the present invention, one exemplary embodiment of a functional why Type: -34- (31) 1287639

File: - TestPlan.h Class CTestPlan { private: unsigned long m_Id; CTestPlanMsgHandler m_tplMsgHandler; } A File: - TestPlan.cpp extern CcmdDispatcher *gjpCmdDispatcher; CTestPlan::CTestPlan { m_tplMsgHandler.setTestPlan(this); gjpCmdDispatcher.AddMsgHandler(&amp ;m_tplMsgHandler) } A CT estPlan: :-CT estPlan { g_pCmdDispatcher.removeMsgHandler(m_Id) The program under DLL's initializes the g_pCmdDispatcher object by calling getCmdDispatcher() exposed by the communication 1. . Display a typical message processing in the CTestPIanMsgHandler category.

File: - TestPlanMsgHandler.h Class CtestPlanMsgHandler : public IMsgHandler { public: setTestPlan(CTestPlan *pTestPlan); setTestPlanProxy(CTestPlanProxy *pTestPlanProxy); void handleMessage(unsigned long msgType, unsigned long senderld, unsigned long senderMsgLen, byte *pSenderMsg) void handleSetName( Unsigned long senderld, unsigned long senderMsgLen, byte *pSenderMsg); void handleGetName(unsigned long senderld, unsigned long senderMsgLen, byte *pSenderMsg); private: CTestPlan mj)TestPlan; -35- 1287639 (32) CTestPlanProxy m _pTestPlanProxy; typedefvoid (CFuncTestMsgHandler ::*handlerFn)(unsigned long, unsigned long, byte*); std::map<int5 handlerFn>m_handlers; } a File: - TestPlanMsgHandler.cpp CTestPlanMsgHandler::Ctest]PlanMsgHandler { m_handlers[HandleError] = handleError; m_handlers[ GetName] = handleGetName; m__handlers[SetName] = handleSetName; } a void CTestPlanMsgHandler::handleMessage(unsigned long msgType, unsigned long senderld, unsigned long senderMsgLen, byte *pSen derMsg) { if (msgType == 0) { handleError(senderId? senderMsgLen, pSenderMsg); else handlerFn fn = NULL; hlter-t flter; flter = m_handlers.fmd(msgType); if (flter == m-handlers.end . ) { a return; } fn = flter->second; if (NULL != in) { (this->*fn)(senderld? senderMsgLen, pSenderMsg); void CTestPlanMsgHandler::handleSetName(unsigned long senderld, unsigned long senderMsgLen, byte *pSenderMsg) { if (m_pTestPlanProxy != NULL) { OFCString tplName = ByteToString(senderMsgLen5 pSenderMsg) -36- (33) (33)1287639 m_pTplProxy->setName(tplName); void CTestPlanMsgHandler::handleGetName(unsigned long Sendld, unsigned long senderMsgLen, byte *pSenderMsg) { OFCString testName; if (m__pTestPlan !=NULL) { unsigned long 1 a destld unsigned long l_msgType; unsigned long l_senderld; unsigned 1 a senderMsgLen; byte *l_senderMsg = NULL; if (m_pTestPlan- >getName(testName) != true) { // If a failure has occurred Send error message char *errorString = "Error retrieving name"; 1 a destld = senderld; l_msgType = HandleError; 1 a senderld = mjd; 1 a senderMsgLen = strlen(enorString); 1 a senderMsg = StringToByte(errorString); sendMsg(]_destId5 1 a msgType, L—senderld, 1 a senderMsgLen, 1—senderMsg); return; } l—destld = senderld; 1—msgType = SetName; long l—senderld = m—Id; 1 a senderMsgLen = testName.length(); 1 a senderMsg = NULL;

StringToByte(testName, &1—senderMsg); sendMsg(l a destld, 1 msgType, ]__senderld5 1—senderMsgLen, 1 a senderMsg); DELETE—BYT giant (1—senderMsg); -37- (34) (34 ) 1287639 void CTestPlanMsgHandler::handleError(unsigned long senderld, unsigned long senderMsgLen, byte 氺pSenderMsg) { OFCString errorString;

ByteToString(senderMsgLen? pSenderMsg, errorString); m_pTestPlanProxy->setError(enOrString); The following C T e s t P 1 a η P r o x y categories are not typical of the proxy host class.

File: - TestPlanProxy.h Class CTestPlanProxy { CTestPlanProxy(unsigned long serverld); ~CTestPlanProxy (); private: CTestPlanProxy〇; unsigned long m—Id; unsigned long m a serverld; CTestPlanMsgHandler m_tplMsgHandler;

File: - TestPlanProxy.cpp extern CcmdDispatcher *g_pCmdDispatcher; CTestPlanProxy: :CTestPlanProxy(unsigned long serverld) { m_serverld = serverld; m_tplMsgHandler.setTestPlanProxy(this); g_pCmdDispatcher.AddMsgHandler(&m a tplMsgHandler) /// initialize the proxy Unsigned long senderMsgLen; byte *pSenderMsg = NULL; msgType = GetName; senderMsgLen = 0; pSenderMsg = NULL; sendMsg(m_clientId? msgType, m_Id, senderMsgLen, pSenderMsg); // Check if the Error string has been set by the message handler. -38- (35) 1287639 if (m_err〇rString.length() != 0) { OFCString errorString = m_errorString; m__error String = MM; throw exception(errorString.c_str〇); CTestPlanProxy::~CTestPlanProxy { g_pCmdDispatcher.removeMsgHandler(m__Id) The g —pCmdDispatcher object should be initialized by calling getCmdDispatcher(). System Architecture and Testing Figure 8 illustrates a nominal test sequence 8 根据 in accordance with an embodiment of the present invention. The test sequence 800 includes a module installation 8〇2 in a test environment 804 that includes test preparation steps 8〇6 and system tests 8〇8. Initially confirmed 8 1 2 (by some external procedures that may be based on the quality control of the seller) a new module 8 1 0 (hardware or software or a combination thereof). Installation 8 0 2 first requires the test preparation step 8.0, which includes the installation of the hardware module simulation of the disconnection simulation 8 1 、, the module resource file and interface installation for the test program development 8 1 2, And the installation of the module-specific type compiler for the type compilation 8 i 4 . Secondly, the system test 8 8 8 is performed with input from calibration 8〗 6, diagnosis 8 18, and architecture 8 2 0. The new module is then systematically tested 8 0 8, which includes:) interface control; (2) synchronization, sequencing, and repeatability; (3) error/warning processing; (4) multiple address control; And (5) multi-device module control. -39- 1287639 (36) Although only a certain exemplary concrete embodiment of the present invention has been described in detail above, those skilled in the art will readily appreciate that many modifications of the exemplary embodiment are possible. Without departing from the novel teachings and advantages of the present invention. Accordingly, all such modifications are intended to be included within the scope of the present invention as defined by the application. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates a conventional tester architecture. Figure 2 illustrates a system architecture in accordance with an embodiment of the present invention. Figure 3 illustrates a soft body architecture in accordance with an embodiment of the present invention. Figure 4 illustrates the use of test categories in accordance with an embodiment of the present invention. Figure 5 is a schematic diagram of a System Language (UML) illustrating the interaction of a tester system and different vendor supplied model resources in accordance with an embodiment of the present invention. Figure 6 illustrates a specific embodiment of an address controller object for managing tests performed by a user maintained by an address controller. Figure 7 illustrates a specific embodiment of an article replacement on the side of the system controller, which represents the address controller object shown in Figure 6. Figure 8 illustrates a test environment in accordance with an embodiment of the present invention. [Description of Symbols] -40- (37) (37)1287639 2 Driver 4 Comparator 6 产生 Generate Benefit 8 Waveform Generator 10 Image Memory 12 Timing Data Memory 14 Wave Memory Data 16 Component 100 System Architecture 102 System Controller 103 System Controller 104 Address Controller 10 6 Enabler 108 Test Module 110 Test Address 1 12 Object to be Tested 114 Load Board 200 Software Architecture 2 2 0 System Controller 222 Interface 224 Frame Category 22 5 External Tools 226 System Tools 2 2 8 System Tools (38) (38) 1287639 230 Communication Library 240 Address Controller 242 User Test Plan File 243 User Test Category 244 Test Category 24 5 Interface 246 Frame Category 247 Interface 24 8 Module Command Implementation 249 Library 2 5 0 Backplane Driver 260 Module 261 Backplane 262 Chassis Slot Interface 2 63 Module Hardware 264 Hard Interface 2 65 Load Board 266 DUT 2 8 0 Module Simulation 281 Analog Frame 2 8 2 Backplane Simulation 2 8 3 Analog Interface 2 8 4 Module Simulation 2 8 5 Analog Interface (39) (39) 1287639 2 8 6 Load Board Simulation 2 8 7 Analog Interface 2 8 8 Program Language Interface 2 8 9 Language Support 2 90 Tester Operating System Interface 291 Model 2 92 User Components 2 93 Model 294 System Components 296 Module Development Components 2 9 8 External Components 6 02 Command Delivery Object 604 Functional Test Message Handler 606 Function Test 6 08 Message Processor Interface 610 Test Interface 7 02 Command Delivery 7 04 Function Test Message Processing Program 7 06 Function Test Agent Host 7 0 8 Message Processor Interface 710 Test Client Interface 7 1 2 Distribution Interface 714 Application 8 00 Test sequence -43 (40) 1287639 8 02 Installation 8 04 Test environment 8 06 Test preparation steps 8 0 8 System test 8 10 Module 8 12 Program development 814 Model compilation 816 Calibration 8 1 8 Diagnostics 820 Architecture

Claims (1)

1287639 (1) Picking up, patent application scope 1 · A decentralized operating system for testing at least one semiconductor test system of a DUT, the operating system comprising: a main operating system capable of being controlled by a system Controlling at least one address controller; and at least one local operating system coupled with each address controller for controlling at least one test module by a combined address controller, wherein at least one test The module performs a test on a corresponding object to be tested. 2. The distributed operating system of claim 1, wherein the primary operating system operates the at least one address controller synchronously. 3. The distributed operating system of claim i, wherein the primary operating system mediates communication between the system controller and the at least one address controller. 4. The distributed operating system of claim 1, wherein the system controller monitors operation of the at least one address controller. 5. The distributed operating system of claim 1, wherein the address controller monitors operation of the at least one test module connected to the address controller. 6. The distributed operating system of claim 1, wherein the primary operating system includes at least one host interface for communicating with the at least one address controller. 7. The decentralized operating system of claim 6, wherein the at least one host interface is for communicating with at least one test module -45 - 1287639 (2) connected to the address controller. 8. The distributed operating system of claim i, wherein the test module interface for defining a test module function program is used to form an interface between the address controller and the first test module. The test module interface can be extended to form an interface between the address controller and the second test module, and the unextended test module interface is insufficient to form an interface between the address controller and the second test module. . 9. The distributed operating system of claim </RTI> wherein the primary operating system comprises at least one primary framework category. 1 0. The distributed operating system of claim 9, wherein the at least one main frame category is developed in a standard computer language to enable a user to develop control of the at least one address controller Application specific category. 1 1. A decentralized operating system as claimed in the patent application, wherein the standard computer language is C or C++. 1 2 . The distributed operating system of claim 1, wherein each partial operating system comprises at least one partial framework category. 1 3 - The distributed operating system of claim 12, wherein the at least one partial framework category is developed in a standard computer language to enable a user to develop control of the at least one test module Application specific category. 1 4 · The distributed operating system of claim 13 of the patent application, wherein the standard computer language is C or C++. 1 5 · For the decentralized operating system of Patent Application No. 1, -46 - 1287639 (3) The number of modules controlled by each address controller is variable. 1 6 · As in the distributed operating system of claim 1, the local operating system combined with a corresponding address controller can re-architect the test module type controlled by the address controller. 17. The distributed operating system of claim 1, wherein the primary operating system is capable of varying the number of address controllers controlled by the system controller. 18. The distributed operating system of claim 1, wherein the primary operating system is capable of varying the number of analytes tested by the testing system. The dispersing operating system of claim 1, wherein the at least one test module comprises a hardware and/or a soft body. 20. The decentralized operating system of claim 1, wherein an emulator is included for simulating the use of a candidate test module with the test system to verify that the candidate module is compatible with the test system. 2 1 . The distributed operating system of claim 1, wherein the first set of frames of the module at the first test site is different from the second set of modules at the second test site. 22. The decentralized operating system of claim 1, wherein the first test site has a first architecture to test the first object to be tested, and the second test site has a second architecture to test the second test site And the first and second test addresses are reconfigurable to form a third test address instead of testing the third test object. 23. The distributed operating system of claim 1, wherein -47- 1287639 (4) the first module at the first test location can access the second module at the second test address. 2 4. The distributed operating system of claim 1 of the patent application, comprising a communication library having a predetermined set of functional programs and interfaces for use with the test module. -48 -