A PC-Based Test System in the Making

What do you use to test a device that delivers 360 joules of energy…besides CAUTION? At Physio-Control, a medical device manufacturer of cardiac monitors and defibrillators for the prehospital and hospital settings, our test engineers were recently asked that question. The answer we came up with was a PC-based system using GPIB instruments and LabWindows®/CVI.

Because our industry is federally regulated, we must adhere to specifications that are becoming more and more strict. Based on these regulations, and also in reaction to a change in our company structure, we were challenged to take a new direction in our test-system development.

Not only did we need to develop functional test systems faster, but each system also had to be reusable. This required test software with a modular programming structure so we could easily leverage off previously generated code. We also had to change from a product-specific test system to a more generalized test hardware platform with reusable, previously documented and validated test software. After carefully reviewing our options, we decided to build a PC-based system using GPIB rack-and-stack instruments and LabWindows/CVI instrumentation test software from National Instruments.

Our new test system is designed to functionally test a lifesaving device known as a defibrillator, which delivers up to 360 joules of energy. A defibrillator is used on someone experiencing ventricular fibrillation. The device restarts a person’s heart by shocking or defibrillating it back into normal sinus rhythm.

We are now developing software and integrating it with the hardware. So far, we have reviewed product specifications for the defibrillator, written manufacturing specifications, transferred specifications into equipment requirements, evaluated equipment requirements to specific hardware from several manufacturers, and appropriated enough capital to purchase equipment to build four test systems.

Matching Instruments to Measurement Needs

Cost considerations ultimately swayed us to base our test system on GPIB instrumentation. We did evaluate VXI; however, after reviewing our hardware requirements, we determined we did not need the speed and size benefits of VXI.

The GPIB instrumentation hardware we purchased comes from several vendors. The instruments and other hardware we selected are outlined in Table 1.

The test system makes various basic as well as some product-specific measurements. Some of the more unique measurements include:

Defibrillator Energy—the 360 joules-type, approximately 5,000 V with 60+A peak current. Our method for measuring energy integrates the current waveform which is captured by a Pearson current monitor and our digital storage oscilloscope.

Defibrillator Waveform Analysis—basically a 50-Hz half-sine wave and the same energy level, peak current, slew rate and pulse width at the 10% and 50% points.

Electrocardiograph Simulation—with low-level differential gain measurements using various waveforms and offsets.

Pacing Pulse Waveform Analysis—(noninvasive pacing sends current to the chest to regulate the heart beat), peak current and associated characteristics.

Selecting the Software

After the purchase orders for the hardware were placed, selecting the test software or compiler was next. Requirements were very general, but a supplier’s potential for longevity was very important. Will the vendor sell and support its product years from now?

We reviewed and tested several software packages and compilers, all from leading software houses and test instrumentation vendors, and concluded that LabWindows/CVI best suited our test needs (Table 2). The reasons for selecting LabWindows/CVI include:

Front Panels—Interactive code development through the use of function panels. When you request information on a particular function, a graphical panel pops up with boxes to enter your specific code requirements, and you can execute this one line of code from within the function panel.

Interactive Code Execution—The capability to have interactive code execution is just as important as interactive code development. With LabWindows/CVI, you can automatically place lines of code developed from function panels into an interactive-execution editor. You can also manually insert code. Then you can debug several lines of code at execution speed and without the overhead of a complete project.

When code is operating as intended, you can simply cut and paste it into your working source code. This is exactly how we evaluated our energy calculations/routine.

Instrument Driver Library—No need to write your own instrument drivers. LabWindows/CVI includes a large library of ready-to-use instrument drivers. These libraries greatly improve our development time because we do not need to know the particular programming protocol of each instrument prior to integrating it into the system.

These features save hours of code development time. For example, when we needed to review our measurement approach of energy, all we had to do was load an instrument driver, pop up the capture waveform routine, and execute. Not one scope manual was opened, and the waveform array was readily available for analysis.

Project Summary

We now have the software program shell, or test executive, up and running. It handles all user inputs, Windows overhead and printing tasks, and can initiate testing. This stand-alone, documented and validated module is reusable; that is, the only UUT-specific coding is the function call to an external functional test module. These external modules are grouped together by functionality, such as energy-related measurements, pacing-related measurements and DC measurements; compiled into object modules, then documented and validated separately.

The execution of these external modules occurs according to an ASCII file or data base. This file contains the individual test numbers, test description, upper and lower limits, expected value for statistical process control purposes, and various details associated with test execution and data logging. The test-execution order also is dependent on the ordering of tests within this file/data base.

To date, we have written and successfully integrated four test modules into the shell program, including Energy Calibration or Verification, Pacing Calibration or Verification, Waveform Miscellaneous, and Pacing Waveform Miscellaneous. This puts the software development integration at about 50% complete.

This is an aggressive commitment considering we have a pilot run scheduled for this summer. Before the pilot run, we must complete hardware and software development and all the documentation packages, and write and execute test-system validations. So far, our development process has gone very smoothly, largely because of the outstanding support of our hardware vendors.

About the Author

Mark Gwin, a B.S.E.E. graduate from Western Michigan University, has worked as a Senior Test Engineer at Physio-Control for the past three years. Physio-Control Corp., 11811 Willows Rd. N.E., P.O. Box 97006, Redmond, WA 98073-9706, (206) 867-4000.

Table 1

Table 2

Copyright 1995 Nelson Publishing Inc.

May 1995