Knowing Your Monitoring Equipment
- 格式：docx
- 大小：1.05 MB
- 文档页数：21
Knowing Your Monitoring EquipmentLabVlEW: A SOFTWARE SYSTEM FOR DATA ACQUISITION, DATA ANALYSIS, AND INSTRUMENT CONTROLCor J. Kalkman, MD, PhD Kalkman CJ.LabVIEW: a software system for data acquisition, data analysis, and instrument control.J Clin Monk 1995;11:51-58ABSTRACT.Computer-based data acquisition systems play an important role in clinical monitoring and in the development of new monitoring tools. LabVIEW (National Instruments, Austin, TX) is a data acquisition and programming environment that allows flexible acquisition and processing of analog and digital data. The main feature that distinguishes LabVIEW from other data acquisition programs is its highly modular graphical programming language, "G," and a larg e library of mathematical and statistical functions. The advantage of graphical programming is that the code is flexible, reusable, and self-documenting. Subroutines can be saved in a library and reused without modification in other programs. This dramatically reduces development time and enables researchers to develop or modify their own programs. LabVIEW uses a large amount of processing power and computer memory, thus requiring a powerful computer. A large-screen monitor is desirable when developing larger applications. LabVIEW is excellently suited for testing new monitoring paradigms, analysis algorithms, or user interfaces. The typical LabVIEW user is the researcher who wants to develop a new monitoring technique, a set of new (derived) variables by integrating signals from several existing patient monitors, closed-loop control of a physiological variable, or a physiological simulator.INTRODUCTIONAlthough computer-based data acquisition systems perse can hardly be classified as "monitors," they play an important role in clinical research and in the development of new monitoring techniques. Commercially available patient monitors and data acquisition systems have many components in common: sensors, transducers that convert real-world signals to voltages, amplifiers, analog-to-digital (A/D) converters that translate voltages to numbers in computer memory, microprocessors that act on the data, and displays that present the user with derived numbers and waveforms. Indeed, many of the functions performed by patient monitors can be emulated with a powerful data acquisition system. Because data acquisition systems are open ended, they provide the user with maximal flexibility in determining the way in which data are processed, stored, and displayed. In this way, data acquisition systems provide building blocks for monitoring applications, rather than ready-to-run integrated software and hardware. The main applications of data acquisition systems in clinical monitoring are logging and integration of signals generated by existing patient monitors and the development and testing of new monitoring paradigms or algorithms. Depending on capabilities, some systems may also be used for simulation and process control, for example, closed-loop control of muscle relaxants or vasoactive drugs. This article describes LabVIEW (Na-tional Instruments, Austin, TX), a software system for data acquisition, data processing, and control as part of a neurophysiological monitoring system, used for research and intraoperative patient monitoring.The Lab VIEW SystemThe LabVIEW system is a software environment for data acquisition and control, originally conceived and developed on a Macintosh computer (Apple Computer, Cupertino, CA), and introduced in 1986. LabVIEW is an acronym for Laboratory Virtual Instrument Engineering Workbench. It has evolved from a program that could send, receive, and integrate datato and from laboratory instruments equipped with a GPIB (general purpose interface bus, conforming to the IEEE-488 standard) into a system that can accept data in both analog and digital formats, and perform data analysis and instrument control. It was the first software program to include graphical, iconic programming techniques, which make the form of programming more transparent, and the sequence of processing visible to the user. The latest release of LabVIEW (version 3.0) is available on three computing platforms: Apple Macintosh, DOS/Windows 3.1, and Sun workstations. Applications developed on one of these platforms can run on another platform with no or only minor modifications.The main feature that distinguishes LabVIEW from other data acquisition programs is the graphical programming language ("G"). It comes with a huge library of mathematical, statistical, and digital signal processing (DSP) functions. Graphical programming means that statements, variables and functions are represented by on-screen icons and "wires," rather than by lines of text. In a LabVIEW program, execution is not controlled by the order in which the statements were written in the source code (line-oriented programming), but, rather, by the data that are generated (data flow oriented). For example, subroutines that use data originating from an A/D conversion board as input do not execute until the data have been acquired.The developers of LabVIEW have consistently used the metaphor of a VIRTUAL INSTRUMENT (VI), mimicking real-world measurement instruments. A LabVIEW virtual instrument consists of a front panel (the user interface) that can both accept input from the user (sliders, knobs, values entered from the keyboard, push buttons, selector switches) and present output to the user (indicators, LEDs, graphs, strip charts, sounds). A Lab- VIEW program (called diagram) somewhat resembles the schematic for an electronic circuit. Wires represent variables that hold data. The various processes that act on these variables are represented byicons (small graphic objects that suggest the operation they perform). All basic elements of conventional programming languages are implemented. For example, CONDITIONAL BRANCHING (IF . . . THEN . . . ELSE) is represented by a CASE structure. Repetitive operations can be put into FOR... NEXT or WHILE loops. In LabVIEW, this literally means moving all of the relevant statements within the screen boundaries of a graphic element that represents the loop.Creating a Lab VIEW ProgramThe creation of a LabVIEW program (virtual instrument or VI) starts with determining which variables will serve as inputs, and placing them on the front panel as controls. A wide selection of customizable graphic elements is available to represent numeric controls, text (string) controls, pop-up menu controls, picture "ring" controls, or picture Boolean controls. Similarly, the outputs from the program are placed on the front panel. Again, the output may be in numerical, textual, or graphical form. The programmer then switches to the underlying diagram, where the newly placed front panel controls and indicators are represented as rectangular boxes. Color and a number inside the box denote data type and precision (INTEGER or FLOATING POINT). The programmer selects functions or subroutines (SUBVIS) from pull-down menus, and connects input and output terminals with the functions using a special cursor, the wiring tool. Color and line thickness of the wires provides information on the data type. Wires representing integer numbers are represented in blue, while FLOATING POINT NUMBERS are represented in orange. Arrays are represented by thicker wires; parallel wires represent multidimensional arrays. Repetitive operations are placed inside a WHILE or FOR-NEXT loop asappropriate. Conditional branching is achieved with the CASE structure, by wiring the condition (either a Boolean TRUE or FALSE, or an integer number) to the condition terminal, a green question mark. Inside the CASE structure, each of the CASEs can be filled with the appropriate actions or subroutines (subVIs). Since it is not possible to have all of the cases visible at the same time, a control at the top border of the CASE structure allows the programmer to step through, and inspect the contents of the various case alternatives. When printing a diagram for documentation, the contents of each case can be printed separately. DEBUGGING is facilitated by the fact that each VI or subVI is a separate program that can be run independently from the calling (main program) by setting the front panel controls, and inspecting the results. Rearranging screen objects can be easily accom plished, and connecting wires will try to adapt in a logicalway. The programmer can improve diagram legibility by minimizing screen clutter and by avoiding crossing of wires or wires that cross under, rather than terminate, in functions or subVIs. Some drawing tools, like alignment anddistribution, are available to help " streamline the appearance of diagrams and front panels.Lab View Example: A Simple Signal AveragerFigure 1 is a diagram of a basic signal averaging virtual instrument. Signal averaging is at the heart of many programs used for acquisition of evoked potentials (EPs). EPs are 1 to 2 orders of magnitude smaller than the electroencephalogram (EEG) from which they must be extracted. The peak-to-peak amplitude of a somatosensory EP may be less than 1 F~V. Signal averaging relies on the fact that evoked potentials are time-locked to the evoking stimulus. By summing and averaging several hundred segments of EEG immediately following the stimulus, background activity ("noise") can be eliminated, while the signal of interest is preserved.The program uses a WHILE loop that continues until the specified number of sweeps has been acquired. A shift register positioned on the boundaries of the loop holds the summation waveform array. Shift registers are a convenient way to "remember" data values acquired or calculated in previous iterations of loops. Data enter the shift register on the right side of the loop, and are available at the left terminal during the next iteration. In the example in Figure 1, each EP sweep is added to the summation waveform. To obtain the averaged EP, the summation waveform is divided by the number of sweeps acquired. Two counters are updated every sweep: The first counter holds the number of averaged sweeps; the other counter holds the number of rejected sweeps. A CASE structure is used as part of the artifact detection algorithm. A dedicated subVI tests each incoming sweep to determine whether one or more of the artifact criteria are met. The result is a BOOLEAN variable (TRUE or FALSE). Onlywhen the artifact criterion is not met (CASE selector = FALSE) will the most recently acquired sweep be added to the summation waveform; otherwise, the sweep is rejected, and the rejected sweeps counter is incremented.Ease of Programming and DocumentationLabVIEW code is quite flexible and reusable. VIs can be nested almost indefinitely. The programmer can design icons for each VI or subVI, and can determine which front panel controls and indicators will be used as terminals to receive or supply data. SubVIs can be set to perform their calculations only, or to open their front panel when called. VIs can be shared among many applications. For example, a digital filter VI might use an array of integer numbers, a cutoff frequency, and slope as inputs, and provide the digitally filtered data at the output. This VI needs to be written only once. It can then be reused in several programs. Another important aspect of LabVIEW is that many operations show POLYMORPHISM" addition, subtraction, multiplication, division; and even some of the more complex operations accept any data type on their inputs. For example, a numeric array may be multiplied by a single number, or two arrays may be multiplied by each other, all by "wiring" them to the same multiplication function icon.A common problem with line-oriented program languages is that unless one meticulously documents every statement and function, the program may rapidly become incomprehensible, not only for others, but, after some time, even for the programmer who designed the program. LabVIEW, by nature of its graphical programming syntax, provides almost self-documenting code; that is, one can usually deduct the function of the program by following the wires to and fromthe various functions and subVIs. In addition, each control, indicator, wire, or function can be individually commented, without cluttering the diagram. The comment can be made visible by clicking on the function. The current version of LabVIEW does not allow collecting and indexing individual comments in a list. Front panels, diagrams, and the hierarchy of subroutines can be. printed. Optionally, the contents of the various CASE alternatives can be individually printed.Timing Considerations and Real-TimeApplicationsThere are several options for controlling the timing of operations or updating of displays. Because the sequence of events in a LabVIEW program is data-driven, processes that use continuous data acquisition proceed at the speed with which data become available, as dictated by the sampling hardware clock. As long as the computer is able to keep up with the processing, display, and/or disk storage of the results, the program will be in sync with acquisition. By reserving buffer space in computer memory, the programmer can provide some "slack" for occasional tasks that require a lot of processor time. The buffer will hold the unprocessed data segments (backlog) until the computer is again available to continue with the processing. The processor will try to make up for the lost time. When the buffer overflows, an error occurs, and data acquisition is halted. In practice, for sampling rates used in clinical monitoring, updating the screen with color graphic objects is the performance bottleneck on most computing platforms. It may be necessary to reduce the update rate of screen indicators and graphs, either by updating them only once every nth iteration of a loop, or by using LabVIEW's pseudo parallel processing. This involves writing the value to be displayed to a GLOBALvariable, and reading and displaying this GLOBAL variable from inside a separate WHILE loop running at a much lower speed. The speed of repetitive operations inside a WHILE loop can be controlled by the acquisition hardware, or by including a software delay function (wait nn msec).Typical Uses of Lab VIEW in ClinicalMonitoringLabVIEW can be used in various ways to receive realworld data. In conjunction with an A/D converter board, analog signals can be acquired, processed and displayed, or written to disk. An example is logging of analog signals from the patient monitor in the operation room for future off-line analysis, or on-screen trend recording. As an extension of this simple data logging, on-line signal processing may be performed on the incoming analog signals, for example, EEG spectral analysis, ECG analysis, analysis of blood pressure waveforms, calculation of heart-rate variability, and pressure/volume or flow/volume loops. The results ofthese computations can be stored on disk and/or displayed on screen.In EP monitoring, triggered acquisition of fixedlength samples is used. An on-board clock generates pulses that simultaneously trigger the stimulator (somatosensory, auditory, visual, or transcranial motor) and the acquisition of neurophysiological signals. Examples include neuromuscular blockade (train-of-four) monitoring, somatosensory EPs, auditory EPs, and transcranial motor EPs. Signal averaging can be employed when the signal-to-noise ratio is too small for the evaluation of single sweep waveforms.LabVIEW also includes an extensive library of functions that enable communication with external devices with an RS-232 serial port or an IEEE-488 interface. This means that, in addition to acquisition of analog signals, the program can communicate with noninvasive blood pressure monitors, pulse oximeters, or some of the more esoteric monitors, such as noninvasive cardiac output monitors, transcranial near-infrared spectroscopy,and transcranial Doppler monitors. The power of LabVIEW in these settings is that data from different signal sources can be acquired simultaneously using analog and digital (serial/parallel) communication and can be integrated to calculate derived values and/ or present the user with meaningful displays.Lab VIEW LibrariesExtensive libraries of functions are available that aid in the acquisition of data using either the serial ports or one of the National Instruments analog or digital input boards. Many of these library VIs contain source code (diagrams) that can be modified by the user. Various windowing functions, spectral analysis, and a large set of digital filters are available to inspect or to alter the frequency content of acquired waveform data. In addition, a large library of statistical functions is available for basic statistics, hypothesis testing, and curve fitting. Manipulation of character strings is supported to facilitate communication with devices via RS-232 or IEEE- 488. To aid user interaction with a LabVIEW program, a large number of on-screen controls and indicators are available from a pull-down menu. These controls and indicators include numeric controls to display or to alter numbers, sliders, knobs, gauges, dials, pointers, and thermometers. Most of these graphic elements can be set to be either a control or an indicator. Boolean controls andindicators available are buttons, knobs, switches, and LEDs. Display of data in graphical form has been made straightforward by the inclusion of resizable graphs that can be positioned anywhere on the screen. The visibility, scaling, labeling, gridlines, colors, and behavior of cursors on these graphs can be set from within the program using attribute nodeLab VIEW Application Example: SomatosensoryEvoked Potentials Monitoring ProgramThis program was designed to perform continuous single- or multichannel monitoring of posterior tibial nerve cortical somatosensory evoked potentials (PTNSEPs). It uses conventional signal averaging of single EEG sweeps (100 to 200 msec) following a somatosensory stimulus applied to the posterior tibial nerve at the ankle. Figure 2 shows the front panel of the SEP monitoring program. The upper trace on the left graph window shows the current average in progress. Below it, in the same window, is shown the previous SEP waveform. A simple algorithm determines the location of the first positive and negative peaks. The ranges in which to search for these peaks are set by the user. To aid in adjusting these ranges, they are indicated as areas of different color on the SEP waveform. This simple algorithm only looks for local minima and maxima in subranges of a low-pass filtered copy of the SEP waveform, and returns the indices of the found peaks. An attractive aspect of LabVIEW is that this algorithm is contained in a separate VI, which accepts the SEP waveform and the boundaries of the search areas, and outputs the peak indices. This VI can be easily replaced by a more sophisticated and robust algorithm, should this become available. The peak latency and amplitude values are written to an ASCII text file, together with the time of acquisition, and user-entered comments, if any. Separate latency andamplitude graphs show trends of latency and amplitude. Optionally, alarm limits may be set to alert the user when the peak data exceed acceptable limits. Finally, the SEP waveforms are plotted in a "history" window using a waterfall-type display similar to that used for compressed spectral arrays in processed EEG. Data points from each completed SEP waveform are combined with additional data (acquisition parameters, start and end times of acquisition, number of sweeps, number of rejected sweeps, and comment string) in a record structure that is automatically written to disk.Motor Evoked Potentials ProgramThis program is a modification of the SEP monitoring program described above. The user can set the number of transcranial stimuli to deliver. For reasons of safety, the transcranial stimulator is manually triggered by the operator while observing the surgical field for movement. This eliminates the chance of inadvertent triggering of the stimulator during phases of the operation where movement by the patien t is undesirable or dangerous. The program acquires electromyogram (EMG) signals from 1 to 8 channels, arid displays these in two graphs (left/right fashion). Each subsequent motor evoked potential (MEP) wavef0rm is superimposed over the preceding waveforms. After each stimulus, the average waveform is also calculated and displayed. Using the simple peak-finding algorithm described above, the maximum and minimum amplitudes in the relevant subrange of the waveform are determined and converted to maximum peak-to-peak amplitude (MEP adult: between 30 and 60 msec poststimulus). These values are displayed and written to an ASCII text file. The original waveforms are written to a binary file combined with time of acquisition, acquisitionparameter settings, and a comment string. Onset latency is determined manually using an on-screen cursor. Automatic determination of onset latency might be implementedin a later stage.DISCUSSIONSeveral aspects come into play when determining which system to use for data acquisition in clinical monitoring. If the only objective is to acquire real-world data and to store them in digital form, many options are available. Many commercially available systems are excellently suited to acquire data from various sources and to integrate them with user-entered data. For example, anesthesia "record-keepers" are preconfigured to interface with a wide array of patient monitors and to accept user input. These programs are not designed for on-line analysis of the incoming data; usually, they are configurable, but not programmable. Various computer programs are available that allow the user to configure PC data acquisition boards for a specific application and acquire data continuously or when user-specified events occur. Some of these programs include analysis functions and various levels of programmability. The other end of the spectrum comprises the development of a stand-alone computer data acquisition/monitoring application using one of the conventional programming languages and data acquisition hardware. When a data acquisition system is used for a specific monitoring function, for example, the acquisition of MEPs, several other aspects should be considered. Can a commercially available monitor perform the required functions? Various developers make neurophysiological monitors that are designed for use in the operating room or monitors that may be used in the operating room with specially developed intraoperative monitoringsoftware. Commercially available monitors have tested hardware and software, and incorporate many safety features. Such a system may be the best choice when existing and generally accepted techniques are to be used. However, when designing new monitoring paradigms or evaluating new techniques, the software architecture of comer cially availablemonitors may be too restricted. Unless the design of a commercial monitor is open-ended and programmable, it is difficult or impossible to implement and test new techniques or algorithms The main advantage of LabVIEW over conventional programming languages is its short development time. Several authors have reported development times up to one-fourth of those needed when using a conventional programming language [1-4]. Another important aspect of the block diagram structure of a LabVIEWapplication is that it is very easy to make instantaneous modifications, for example, to add an indicator to the front panel. This modification typically can be accomplished in minutes. When programs need constant updating and modifying in the course of an evolving experimental setup or new monitoring technique, this feature becomes an especially invaluable asset. The key element in LabVIEW's commercial acceptance has been that it has allowed nonprofessional programmers, typically the end-user/researcher, to write his/her own data acquisition and processing applications, without having to worry about the tedious details of low-level programming of data acquisition hardware. LabVIEW supports all National Instruments hardware: A/D converters, digital-to-analog (D/A) converters, digital INPUT/ OUTPUT (I/O) boards, and digital signal processing boards. Driver software that allows LabView to use third-party hardware is sometimes available from the manufacturer, while National Instruments maintains a large library of instrument drivers for communication with GPIB laboratory measurement instruments.Ease of Programming~Learning CurveAlthough it is relatively easy to master programming in LabVIEW, even with limited previous experience in computer programming, there is a learning curve of several weeks to months before one feels comfortable with the system and is able to build applications that involve more than the most basic data acquisition, processing, and file I/O. This makes LabVIEW less suitable for the casual user of data acquisition systems, who may feel more at ease with shell-type data acquisition systems, where data acquisition can be set up using menus and a scripting language to chain availablecommands. In contrast, a well-designed completed LabVIEW application can be extremely user-friendly, even for the nontechnical user/operator.Limitations of Lab VIEWLabVIEW is a powerful programming environment; but, this power comes with a price. On-screen software controls and indicators use a large amount of computer overhead. Because the computer monitor serves both as the control center and data display area, a large-screen color monitor is a must. Also, a powerful computer is needed. Although good LabVIEW programming "style" dictates that one should break down a large program into several smaller subVIs, a LabVIEW diagram can rapidly become quite large. A large monitor speeds up programming time because more of the diagram is visible at any given time and there is less need to scroll back and forth. Fortunately, the price of the computer power and color displays needed for such computationintensive environments has decreased dramatically; these systems may now be within reach of many academic institutions. Some professional programmers value execution speed over flexibility and are reluctant to change from a linear programming language (C, Pascal) to LabVIEW.Validation and Quality ControlDesigning monitoring applications using data acquisition/ programming systems like LabVIEW means that the user/programmer is fully responsible for quality control and debugging of his own software. Moreover, National Instruments does not endorse the use of LabVIEW or any of their hardware components for use in clinical research or patient care. This means that theLabVIEW programmer/user is also responsible for any errors in the hardware and software that could potentiallyjeopardize a patient's safety. This is particularly true for any connections between sensors or actuators on the patient and the computer (need for optical isolation). The speed and ease of developing full-functioning data acquisition/processing applications by nonengineers/ nonprogrammers has a potential downside. Inadequate knowledge of data acquisition basics, such as sampling theory (Nyqvist frequency) can result in computer programs that produce erratic results because of conceptual errors. Several publications and user groups can help the novice LabVIEW programmer with the design and implementation of his/her application. National Instruments provides excellent documentation in the form of a variety of user manuals, free distribution of technical notes, and maintenance of a BBS service, which can be reached by telephone ((512) 794-5422), or the Internet (). There is also a LabVIEW@mailing list on the Internet (info-labview@ pica.army.rail). Requests for subscriptions should be sent to info-labview-request@. In many countries, there are regular meetings of LabVIEW user groups, where information is exchanged.Potential dangers in a monitoring situation exist only when wrong assumptions and clinical decisions would be based on invalid data, either as result of hardware failure or software error. However, should a researcher decide to use LabVIEW to implement closed-loop control of a physiological process (for example, adjusting vasodilator therapy based on the patient's responses [5]), then there is a significant risk of potential danger. A multitude of potential errors, beginning with the blood pressure transducing system and sensor, all the way up to computer control of the infusion pump, could jeopardize the patient. The discussion of quality control of software used in patient care has only recently gathered force [6-9]. It will become increasingly important, given the。
