Object oriented scaleable test executive

[0002] The present invention generally relates to test systems and in particular to a test executive software system and a method for developing tests to verify the functionality of industrial control modules.

[0003] Industrial controllers are special purpose computers used for controlling factory automation devices. Under the direction of a stored program, a processor of the industrial controller examines a series of inputs reflecting the status of a controlled processor or device and changes outputs affecting control of the controlled process or device. The inputs and outputs may be of an analog or digital nature. Generally industrial controllers are constructed in modular fashion to accommodate different application requiring different numbers and types of input/output (I/O) circuits as are determined by the particular device or process being controlled. In such modular systems, a number of different functional modules connect together through a common backplane in a rack to share data and power. However, other types of modules forming industrial controller solutions include communication modules adapted to provide communication links, counter/encoder modules for monitoring motor position information, programming modules adapted to be programmable to function according to a user's instructions, relay modules typically provided to shut off automated devices and control modules adapted to control and operate industrial control modules.

[0004] Prior to the introduction of industrial control modules into a factory environment, the modules are tested by a test system to verify the proper operation and functionality of the industrial control module. These test systems employ software to control and operate instrumentation that provide input stimulus and perform measurements to verify the proper functional operation of the industrial control modules. Typical test system software employed to test industrial control modules suffer from several deficiencies. For example, most test system software includes instrumentation drivers that are customized for that particular instrument. Typically these drivers are embedded within the actual product test code. When this instrumentation becomes out of date or obsolete, new drivers must be written or installed to operate the new equipment requiring updates to all product tests utilizing this instrument. Furthermore, most test system software is written to function in a particular operating system and is not portable to other operating systems. Additionally, during the test development process, a test developer needs access to a test system and the instrumentation of the test system to verify that a test written by the developer will operate properly. Therefore, time-sharing of the test system is employed between test developers causing reduced throughput of tests ready for implementation into production. Typically, tests are verified by running tests during development with the instrumentation off, so that damage to the instrumentation does not occur. However, a developer cannot be assured that a test will operate properly until the test is run with the instrumentation on. A developer cannot be absolutely assured that a test will not cause damage to instrumentation or the unit under test once the instrumentation is live, until all the errors are eliminated from the test.

[0005] Therefore, it is apparent that there is an unmet need for a test software that is employed on a test system that mitigates the aforementioned deficiencies.

[0006] The present invention provides for a test system having a test executive software system for performing tests on industrial control modules. The test executive software system includes a test kernel component that provides control through a generic interface to the test executive software. Test components, instrument components, support objects and test system interface components are communicatively coupled to the test kernel component. The generic interface allows for easy substitution or replacement of components without affecting the basic functionality of the test executive software. The instrument components can be written as dynamically linked library (DLL) files, so that the instrument component can be broken into basic functional modules associated with the particular instrument type. This allows for simple editing of the DLL for replacing obsolete instruments with other instruments without effecting product test applications. Each instrument component supports operation in both live mode and virtual mode, so that testing can be performed in both normal mode and simulation mode. Operating a test in simulation mode allows debugging of test components without the need for instrumentation. Simulation mode also allows for test development at a remote location on a standard personal computer.

[0007] In one aspect of the invention, a test template file(s) is provided that includes a plurality of test type level functions, function calls and standard instrument library calls that are all commented out. A test developer then uncomments the test type level functions, function calls and standard instrument libraries for that particular unit for which a test is being developed. The test developer then inserts test code into the functions and compiles the code to provide the test for that particular unit under test. The developer can employ a plurality of macros containing standardized code for the development of tests. This facilitates quick and error free development of tests. Preferably, the test template file(s) is also set up as a dynamically linked library and can be placed in the appropriate location after compiling to allow linking at runtime.

[0008] One particular aspect of the invention relates to a system for testing industrial control modules. The system comprises at least one instrument adapted to provide input stimulus and measurement readings for testing an industrial control module and at least one instrument component communicatively coupled to the at least one instrument. The system further comprises at least one test component adapted to provide a program flow to the input stimulus and the measurement readings of the plurality of instruments and a test kernel component adapted to provide a generic interface to the least one instrument component and the at least one test component.

[0009] Another aspect of the present invention relates to a method for developing tests for testing industrial control modules. The method comprises the steps of providing at least one test template file with a plurality of test level type functions commented out and uncommenting at least one of the test level type functions of the plurality of functions for testing an industrial control module. Code is then inserted into the at least one of the test level type functions employing a plurality of macros to provide functionality to the at least one of the test level type functions and the at least one test template file is linked to at least one instrument component. The at least one test template file is then executed in simulation mode to determine if the at least one test template file operates properly. Once it is determined that the at least one test template file operates properly the at least one test template file is executed in normal mode to test the industrial control module.

[0010] Another aspect of the present invention relates to a test system having a test executive software system having computer executable components. The system comprises a test kernel component providing a generic test system interface for the test executive software system and at least one instrument component communicatively coupled to the test kernel component. The at least one instrument component provides control to at least one instrument of the test system. At least one test component is communicatively coupled to the test kernel component. The at least one test component provides a test flow for testing a unit under test wherein the test kernel component initializes the test system and loads and executes instructions of the at least one test component and provides control information to the at least one instrument component based on the instructions of the at least one test component.

[0011] To the accomplishment of the foregoing and related ends, the invention, then, comprises the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative embodiments of the invention. These embodiments are indicative, however, of but a few of the various ways in which the principles of the invention may be employed. Other advantages and novel features of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the drawings.

[0012] FIG. 1 illustrates a block diagram of a test executive software system in accordance with one aspect of the present invention;

[0013] FIG. 2aillustrates a block diagram of an instrument subsystem in accordance with one aspect of the present invention;

[0014] FIG. 2billustrates a portion of a dynamic link library file for a digital multimeter in accordance with one aspect of the present invention;

[0015] FIG. 3 illustrates a pop up window for a test template project folder in accordance, with one aspect of the present invention;

[0016] FIG. 4 is a flow diagram illustrating one particular methodology for developing a test programs in accordance with one aspect of the present invention;

[0017] FIG. 5aillustrates an example of a test template moduletest.h file in accordance with one aspect of the present invention;

[0018] FIG. 5billustrates an example of a test template Cmoduletest.cpp file in accordance with one aspect of the present invention;

[0019] FIG. 6aillustrates a test project development screen with a test template file disposed in an editable area in accordance with one aspect of the present invention;

[0020] FIG. 6billustrates invocation of a Macro function in the Tools menu of the test project development screen of FIG. 6ain accordance with one aspect of the present invention;

[0021] FIG. 6cillustrates a Macro function pop-up menu displayed from invocation of the Macro function in the test development screen of FIG. 6bin accordance with one aspect of the present invention;

[0022] FIG. 6dillustrates insertion of code in a function of the test template file by selection of one of the Macros displayed in the Macro function pop-up menu of FIG. 6din accordance with one aspect of the present invention;

[0023] FIG. 7aillustrates an example of a test template moduletest.h file with selected test level types and selected instruments uncommented in accordance with one aspect of the present invention;

[0024] FIG. 7billustrates an example of a test template Cmoduletest.cpp file with a simple test employed in a selected test level type in accordance with one aspect of the present invention;

[0025] FIG. 8 illustrates a graphical user interface window with an example of a dialog box that is displayed when operating in simulation mode in accordance with one aspect of the present invention;

[0026] FIG. 9aillustrates a graphical user interface window as seen by a test operator when a UUT passes a test in accordance with one aspect of the present invention;

[0027] FIG. 9billustrates a graphical user interface window as seen by a test operator when a UUT fails a test in accordance with one aspect of the present invention;

[0028] FIG. 10 illustrates a perspective view of a test system in accordance with one aspect of the present invention;

[0029] FIG. 11 illustrates a front view of a test bay of the test system of FIG. 10 in accordance with one aspect of the present invention; and

[0030] FIG. 12 illustrates a front view of an instrument bay of the test system of FIG. 10 in accordance with one aspect of the present invention;

[0031] The present invention will now be described with reference to the drawings. The present invention will be described with reference to a test system having a test executive software system for testing industrial control modules. The present invention also provides for a method for developing tests for industrial control modules. It is to be appreciated that the present invention is described with respect to the testing of industrial control modules, but may be employed to test other types of products. It should be understood that the description of the various aspects of the present invention are merely illustrative and that they should not be taken in a limiting sense.

[0032] FIG. 1 illustrates a schematic block diagram of a test executive software system 10 provided with a test kernel component 14 (system control object). The test kernel component 14 is communicatively coupled to a test system interface component 12, instrument components 16, support objects 18 and a plurality of test objects 20. The kernel component 14 is a central interface component that provides a generic interface to all components of the test executive software system 10. The kernel component 14 provides application program interfaces (APIs) to other test software components so that replacement of components is easily facilitated. For example, the test system interface component 12 can be a graphical user interface provided to a test operator for manual control of testing industrial control modules or other units under test (UUTs).

[0033] Alternatively, the test system interface component 12 can be an automated handler component that provides for automated testing of UUTs. The interface component 12 has no knowledge of other system components, other than the API exposed by the kernel component 14, thus supporting the design criteria of loosely coupled software components for maximum modularity. Furthermore, the test kernel component 14 allows for the instrument components 16, test objects 20 and support objects 18 to be easily replaced with other components and objects without affecting the overall functionality of the test executive system software 10.

[0034] Preferably, the kernel component 14 can also load and unload the test objects 20. The test objects 20 are the actual tests that were developed by a test developer. Preferably, the test objects 20 are explicitly linked dynamic linked libraries (DLLs). The kernel component 14 can also provide catch and process errors “thrown” by other software sub-systems, such as the instrument components 16. Since errors are thrown, test developers don't have to worry about the return status of library functions. Additionally, the kernel component 14 can provide test system initialization, define a standard API for use by the test system interface, supports sample testing, generate test reports and test yield data that can be inserted into a “Quality Information System” database used for statistical process control. The support objects 18 can provide functions such as system reset, failure tickets (e.g., Content, Format, . . . ), history files, data verification routines and test system self test.

[0035] The present invention may be implemented via object oriented programming techniques. In this case each component of the system, could be an object in a software routine or a component within an object. Object oriented programming shifts the emphasis of software development away from function decomposition and towards the recognition of units of software called “objects” which encapsulate both data and functions. Object Oriented Programming (OOP) objects are software entities comprising data structures and operations on data. Together, these elements enable objects to model virtually any real-world entity in terms of its characteristics, represented by its data elements, and its behavior represented by its data manipulation functions. In this way, objects can model concrete things like people and computers, and they can model abstract concepts like numbers or geometrical concepts.

[0036] The benefit of object technology arises out of three basic principles: encapsulation, polymorphism and inheritance. Objects hide or encapsulate the internal structure of their data and the algorithms by which their functions work. Instead of exposing these implementation details, objects present interfaces that represent their abstractions cleanly with no extraneous information. Polymorphism takes encapsulation one step further—the idea being many shapes, one interface. A software component can make a request of another component without knowing exactly what that component is. The component that receives the request interprets it and figures out according to its variables and data how to execute the request. The third principle is inheritance, which allows developers to reuse pre-existing design and code. This capability allows developers to avoid creating software from scratch. Rather, through inheritance, developers derive subclasses that inherit behaviors which the developer then customizes to meet particular needs.

[0037] In particular, an object includes, and is characterized by, a set of data (e.g., attributes) and a set of operations (e.g., methods), that can operate on the data. Generally, an object's data is ideally changed only through the operation of the object's methods. Methods in an object are invoked by passing a message to the object (e.g., message passing). The message specifies a method name and an argument list. When the object receives the message, code associated with the named method is executed with the formal parameters of the method bound to the corresponding values in the argument list. Methods and message passing in OOP are analogous to procedures and procedure calls in procedure-oriented software environments.

[0038] However, while procedures operate to modify and return passed parameters, methods operate to modify the internal state of the associated objects (by modifying the data contained therein). The combination of data and methods in objects is called encapsulation. Encapsulation provides for the state of an object to only be changed by well-defined methods associated with the object. When the behavior of an object is confined to such well-defined locations and interfaces, changes (e.g., code modifications) in the object will have minimal impact on the other objects and elements in the system.

[0039] Each object is an instance of some class. A class includes a set of data attributes plus a set of allowable operations (e.g., methods) on the data attributes. As mentioned above, OOP supports inheritance—a class (called a subclass) may be derived from another class (called a base class, parent class, etc.), where the subclass inherits the data attributes and methods of the base class. The subclass may specialize the base class by adding code which overrides the data and/or methods of the base class, or which adds new data attributes and methods. Thus, inheritance represents a mechanism by which abstractions are made increasingly concrete as subclasses are created for greater levels of specialization.

[0040] The present invention can employ abstract classes, which are designs of sets of objects that collaborate to carry out a set of responsibilities. Frameworks are essentially groups of interconnected objects and classes that provide a prefabricated structure for a working application. It should also be appreciated that the test executive kernel 12 and the test system interface component 12 could be implemented utilizing hardware and/or software, and all such variations are intended to fall within the appended claims included herein.

[0041] Each instrumentation component can be written as a separate dynamic link library (DLL) that is part of a base class of an instrument subsystem. Each DLL includes several components that form the basic functionality (e.g., reset, self test, setup and read components) associated with that type of instrument. This allows for easy removal and replacement of out of date or obsolete instruments with minimal modifications to the DLL associated with that particular instrument type without effecting each product test. FIG. 2aillustrates an instrument subsystem 30 referred to as an instrument base class having a plurality of DULs associated with the operation of particular instrument types. An example of possible instrument types are illustrated in FIG. 2aand include the following types (and DLLs): digital multimeter 32 (DMM.DLL), data acquisition unit 34 (DAQ.DLL), AC power supply 36 (ACPWR.DLL), digital I/O 38 (DIO.DLL), DeviceNet communication link 40 (DNET.DLL), function generator 42 (FUNCTGEN.DLL), DC power supplies 44 (DCPWR.DLL), electronic load 46 (ELOAD.DLL), relay 48 (RELAY.DLL) and serial port communication link 50 (RS232.DLL). It is to be appreciated tat the above device types and DLLs are only exemplary and other device types and DLLs may be provided based on the associated products to be tested (e.g., printer, other communication links). Each instrument type can include a predefined public interface and be developed as a class library. This modular approach addresses the hardware obsolescence issue seen on other test architectures. An instrument can be replaced with another without affecting the individual test programs that use it.

[0042] In a preferred aspect of the invention, each instrument type supports virtual mode. This allows the ability for a test program to run in simulation mode. Each instrument obtains its operating parameters from an initialization file and each instrument class library preferably supports a reset and self test function. As the name implies, the reset function will reset the instrument to its power on state. The self test function will instruct the instrument to perform its internal self test. Each instrument DLL has code incorporated into components of the DLL that allow for tests to be operated in either virtual mode or live mode. FIG. 2billustrates a portion of code 60 associated with a digital multimeter DLL. The portion of code 60 includes code 62 that sets and returns variables, while employing the DLL during virtual mode. This allows a test developer to develop tests at a remote location uncoupled to a test system (e.g., desktop personal computer) employing the test executive software system 10, while still receiving results that the developer would receive if operating the test on the test system with live instruments. Therefore, several developers can develop, run and debug tests without a test system and be confident that the test will run on the test system without any major problems.

[0043] The test executive software system 10 supports two modes of operation, simulation and normal mode. The normal mode of operation is that which is used to actually test products on the system. In this mode, all of the equipment required to test a product should be installed and operational in the test system. The simulation mode is used when a developer wants to develop code without needing a test system. This mode allows a developer to write, compile, and debug program logic. The following section defines how a system is configured to operate in these two modes. First, to define whether or not the system is operating in simulation mode, an environmental variable, “Simulation” is set to true on the system running the test executive software system 10. If this environmental variable is set to true, the test executive software system 10 will run in simulation mode. If this environmental variable is set to false or not defined, then the test executive software system 10 will run in normal mode. Next, the instruments need to be setup to operate in virtual mode or normal mode. This is accomplished by setting a “Live” parameter associated with each instrument in an instrument.ini initialization file residing on the system where the test executive software system 10 is to be executed. If the “Live” parameter is set to 1 for the instrument in this file, the instrument is to operate in normal mode. If the “Live” parameter is set to 0 for the instrument, it is to operate in virtual mode. Below is an example of the settings of the digital multimeter in an instrument.ini file defined to operate in virtual mode.

[0044] [DMM_1]

[0045] TYPE=DMM

[0046] PRIMARY_ADDRESS=22

[0047] LIVE=0

[0048] FIG. 3 illustrates a pop-up box 70 having a test template project folder 72. In the example of FIG. 3, the test template project folder 72 is a Microsoft Visual C++ (MSVC++) project template employed to simplify the test development process. The test development language of the example is “C/C++”. The IDE (Integrated Development Environment) chosen to debug and compile the tests is “Microsoft Visual C++6.0”. In an effort to make the test development process as simple as possible, a MSVC++ project template was created. This test template project folder already contains the correct project settings to create the test DLL (Dynamic Link Library). The test developer does not need to worry about creating the correct project type, setting up the required paths for such things as include files and library files, and many other details contained within the project settings.

[0049] The only files a test developer needs to modify for testing a particular UUT are the test template files CmoduleTest.h, CmoduleTest.cpp, and TestTemplate.ini. Furthermore, through use of the “#error preprocessor directive”, a test developer is directed to areas of the test template files that require attention. This ensures consistency between test programs as well as minimizing the programming errors. After successfully compiling and debugging a test, the finished DLL is moved to where all test DLL's reside. The test will automatically appear as a selectable item in a graphical user interface.

[0050] FIG. 4 is a flow diagram illustrating one particular methodology for developing a test employing the test executive software system of the present invention. In step 100, a test developer copies the test template files moduletest.h, test.ini and Cmoduletest.cpp into a directory. In step 110, the test developer uncomments test level types to be employed for the unit under test in the test template moduletest.h file and modifies the test template test.ini file to include those test level types. In step 120, the test developer writes tests in the functions of the test level types of the test template Cmoduletest.cpp file using macros in the compiler. The test developer then compiles and links the tests in step 130. The tests are then run in virtual mode in step 140 to verify and debug the tests. In step 150, it is determined if the tests have been debugged. If the tests have been debugged (YES), the tests are run in live mode in step 160. If the tests have not been debugged (NO), the developer returns to step 120 to modify the tests until the tests have been debugged.

[0051] FIG. 5aillustrates an exemplary test template moduletest.h file 200 having a plurality of system include files 202. The test template moduletest.h file also includes a class CmoduleTest 204 having a plurality of function calls 206 reflecting the different test level types to be employed in the testing of a UUT. A test developer can simply uncomment the test level types to be employed in the test and add any necessary private and protected data members and functions to the test template moduletest.h file. FIG. 5billustrates a portion of an exemplary test template Cmoduletest.cpp file 210 having a plurality of test level type functions 212. A developer can simply write their tests within the test level type function for testing the particular UUT that the test is being developed for functionally verifying. It is to be appreciated that the moduletest.h file and the Cmoduletest.cpp file could be combined into a single test template file if so desired.

[0052] An example of available test level types can be as follows: ambient, burn-in, cycle ambient, cycle hot, cycle hot ambient, dynamic hot, dynamic hot sampling, dynamic hot sampling audit, hipot, preheated hot, alignment, download, calibration, troubleshooting, cable, final, functional module and functional system. Each of the above test level types is a section within the “test.ini” file and contains the following entries: ENABLE_LEVEL; set equal to 1 if the test level type is to appear in the test level selection box of the GUI, QIS; set equal to 1 if QIS data used for Statistical Process Control is to be automatically retrieved and uploaded to a QIS server, WIN; set equal to 1 if the test operator is to be prompted to enter the WIN (Warrantee Information Number), ASA; set equal to 1 if the test operator is to be prompted to enter the ASA number (module serial number), DATALOGGING; set equal to 1 if the local history files are to be generated and FIXTURE_ID; enter the fixture ID required by this product.

[0053] The present invention provides for simplification of the development process by employing macros containing code used in testing units under test (UUTs). An example of a list of possible macros is contained within an appendix attached to the end of this specification. FIGS. 6a-6dillustrate an example of the steps employed to utilize the macros of the present invention to develop tests. FIG. 6aillustrates a screen employing Microsoft Visual C++ with a test template Cmoduletest.cpp file 222 displayed in a window 220. A test developer simply places a cursor (e.g., utilizing a mouse pointer) in the respective test level type function uncommented in the test template moduletest.h file. The test developer will then select the Macro option in the Tools menu as illustrated in FIG. 6b. A Macro selection menu 224 will then be displayed to allow a developer to select between a list of macros as illustrated in FIG. 6c. The test developer will then select a macro from the Macro selection menu and click on the “Run” box to insert a portion of test code 226 into the test level type function as illustrated in FIG. 6d. The test developer can continue this process until a complete test has been developed. Additional code can be typed into the test level type function to customize the test.

[0054] FIGS. 7a-7billustrates an exemplary test template moduletest.h file 250 and a portion of a test template Cmoduletest.cpp file 270 for performing a simple measurement with a digital multimeter according to the present invention. Referring initially to FIG. 7a, the functions FunctionalModule( ) and Initialize System( ) in the test template moduletest.h file have been uncommented out of a section of a plurality of test level types 252. Additionally, the variable definitions 254 of the instruments for the digital multimeter, the first and third DC power supply, the relays and the digital I/O have been commented out for the plurality of instrument to be used in the test. A simplified test written in C++ is shown in the Functional module test type of a portion of the test template Cmodule.cpp file 270 illustrated in FIG. 7b. The test utilizes relays to connect the DC power supply to the digital multimeter and to verify that the DC power supply has been programmed to a specified voltage.

[0055] As previously stated, the test executive software system allows the test to run on a desktop PC without the actual test hardware (e.g., instruments) by operating in simulation mode. This allows the test developer to write, compile, and debug program logic before actually needing a test system. This reduces capital expenditures and increases the overall productivity of the test developers. If the test system is operating in simulation mode and all of the instruments are operating in virtual mode, a dialog box 282 illustrated in FIG. 8, is displayed over a graphical user interface window 280, to the user when running their test. The dialog box 282 is displayed anytime the test program tries to verify a value. The dialog box contains the following information; Test Step, Test Description, Expected Measurement Data Type and Expected(Min, Max and Units). If the user selects the “Use Nominal Value” button, the simulated measured value will be the nominal value. If the “Use Measured Value” button is selected, the value entered in the “Measured Value” edit control box is used as the simulated measured value. FIG. 9aillustrates a graphical user interface window 290 as seen by a test operator. In order to perform a test, the operator selects a product from the tree control on the left side of the screen; In FIG. 9a, the product family selected is the 1734 product line and the catalog number selected is the 1734OB4E. Now, the test library is loaded and catalog number, test level, process, and operator controls are updated to reflect the current product being tested. When the operator selects one or more test levels from the level list control and then presses the “TEST” button, the product test begins to execute. If the product successfully passes its tests, the result will resemble FIG. 9aThe progress bar changes its color from BLUE to GREEN indicating that the test has passed. If the product failed one of its test steps, the result is illustrated in FIG. 9bThe progress bar changes its color from BLUE to RED indicating the test failed, the test system executive software then terminates the test. Optionally, the test executive software can display and/or print the failure information.

[0056] Referring now to FIG. 10, a test system 310 illustrating an environment of the present invention is shown. The test system 310 has an instrument bay 312 and a test bay 314. A tester interface panel 316 resides on top of the test bay 314. The tester interface panel 316 is adapted to receive and mate with a test fixture interface panel for testing industrial control modules of various product families and product types having different functional capabilities. A computer display 318 and a computer keyboard 322 are coupled to the test bay 314 and provide user interface capabilities to the test system 310.

[0057] FIG. 11 provides a more detailed description of the test bay 314. The test bay 314 includes an operator panel 320. The operator panel 320 includes components such as an emergency stop button, a printer, a barcode reader port, an operator connection and a ground connection. It is to be appreciated that various other operator interface components can be provided on the operator panel 320. The test bay 314 also includes DC power supplies 324, 326 and 328. The DC power supplies 324, 326 and 328 provide power for powering up industrial control modules under test (hereinafter referred to as unit under test (UUT). The DC power supplies can also provide DC power for UUTs that utilize DC voltage as an input signal (e.g., DC input modules). The test bay 314 also includes a computer 330 coupled to the display 318 and the keyboard 322. The computer 330 can be programmed to provide a variety of different communication protocols utilized in testing different UUTs (e.g., RS-232, DeviceNet, ControlNet, USB). A blower 331 is provided in the test bay 314 to ensure that components within the test bay 314 remain cool during operation of the test system 310.

[0058] FIG. 12 provides a more detailed description of the instrument bay 312. The instrument bay 312 includes instruments that provide measurements of UUT characteristics and parameters having a variety of differing functionalities. The instruments also provide input and output stimulus similar to the stimulus that the UUT will experience in its normal operational environment. The instrument bay 312 houses a data acquisition system (DAQ) 340, a waveform generator 342, a DC voltage calibration/simulator 344, a digital multimeter 346, an electronic load 348 and an AC power supply 350. A blower 351 is provided in the instrument bay 312 to ensure that the instruments within the instrument bay 312 remain cool during operation of the test system 310.

[0059] What has been described above are preferred aspects of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the present invention, but one of ordinary skill in the art will recognize that many further combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.