Architecture drives test system standards

To automate test and measurement systems in R&D and manufacturing settings, it is common practice to connect the instruments to computers. With modern programming languages and a simple setup, the task is no harder than calling up a simple function. The only remarkable aspect is that this function communicates with a hardware device that either measures or stimulates some aspect of the physical world. Grouping the functions needed for controlling an instrument forms a library, which is called an instrument driver. Above all, instrument drivers are convenient. They can be used to build test and measurement systems having interchangeable elements, so that the systems can be maintained through, and despite, changes in the computer, the instruments, and the device under test (DUT). Basically, the drivers encapsulate the various I/O operations between computer and instrument. They are also a convenient interface for those test programs that use instruments. And-an important benefit-they help to insulate the test system from changes made in the underlying instrument hardware. In theory, a test engineer should be able to exchange a new instrument for an existing one within a system and reconfigure that system to use the appropriate driver. In practice, further work is unavoidable before the system will behave as it did before the exchange. Several solutions are being considered by instrument vendors and end-users, including exactly how to exchange instruments within a system, and to what standards a particular driver or system should conform