NODAS-The network-oriented data acquisition system for the medical environment

Transcription

1 NODAS-The network-oriented data acquisition system for the medical environment by SHELLEY I. SAFFER, DAVID J. MISHELEVICH, SHIRLEY J. FOX and VICTOR B. SUMMEROUR University of Texas Health Science Center at Dallas Dallas, Texas ABSTRACT A network-oriented distributed computing system designed for the medical, multi-laboratory environment is described. The development of this network was motivated by the need for a real-time computing system which offers the speed and responsiveness of a dedicated processor and the convenience and cost-effectiveness of resource sharing. The system, a star configured network, utilizes a DECsystem-IO time-sharing system as its host and small memoryonly PDP-II processors as satellites. Program development for the satellite processors can be performed on the host in a higher-level language developed especially for the network. Also present are such network capabilities as downline loading and remote file manipulation. analog signals. In this context, the term "real-time" involves externally-controlled, time-constrained data which is not readily-reproducible, or involves direct control. 1 However, the varied nature of medical laboratory research presents a wide variety of real-time situations. Some laboratory applications, for example, may merely require the automated acquisition of digital data from a laboratory instrument at a reduced rate (perhaps as slow as one sample every 30 minutes). Laboratories with such low-speed requirements could very well be serviced by a centralized single CPU facility. On the other hand, a laboratory function may require the sampling of a number of analog signals every millisecond for a long period of time. Such rapid ND conversion may dictate the exclusive use of a dedicated computer performing only one time-critical task. INTRODUCTION The type of computing facility which best serves the realtime computing requirement of the multi-laboratory medical environment must be more flexible than either the smaller in-lab, dedicated computer system or the larger, multi-user, centralized system. The concept of a single centralized processor for multi-laboratory use offers the advantages of ~"';I@, "'.UUiR~~,.4i)RGQYRhM "" ~1"'A1~~d}I=Qu~b,~ut and availability. In contrast, the concept of the dedicated "in-lab" computer system offers instant computational availability but may have the disadvantage of uneconomical utilization of resources. However, through a network configuration, combining both the centralized and dedicated processor concepts, a computing system with the advantages of both can be realized. Such a network is now being utilized by the Medical Computing Resources Center at the University of Texas Health Science Center at Dallas in order to augment existing minicomputer capability and in some cases obviate the need for laboratory investigators to obtain their own complete minicomputer systems. THE MEDICAL LABORATORY ENVIRONMENT In the medical laboratory environment, real-time applications usually involve relatively high speed acquisition of COMPARISON OF IN-LAB AND CENTRALIZED SYSTEMS The dedicated in-lab processor has the advantage of giving real-time capability at the instant it is needed. This is an important attribute since time-critical functions are not likely to wait for a multi-user computer system to become available. In many medical laboratories. real-time systems ", _, -ff-.~, ~~-'-r-ir_-~~,, o-, O-:'"'f~~<--~~"':-T""::-~'.::-':~_"--:-_-'.~"~~"-;-_';-:_'~.-:<::.=-'-.!.=-\-;_-'-"-.!"~!'-~--c...!:.-~_~-;f~.-:a.. u:')ually \.UII:')i:')l vi :'IHalJ ;:'IHgH;;-U;:'CI ijl U\,,,;');')UI;') u~u..~ul~u.u a particular task. These systems have proven to be a valuable tool and their success has increased the demand for more computing power in the laboratory. As a result, more and more is expected from these small computers which reveals an inherent weakness in the dedicated computer approach. Although a basic processor is relatively inexpensive when purchased, it soon becomes evident that extra memory, fast-access bulk storage, and higher-speed alphanumeric 110 devices are necessary to increase program development capability as well as system productivity. Soon the investment can become sizable and expensive equipment, maintenance, and extra personnel may drain the funds needed for the very research which the computer is supposed to facilitate. This is not to say that such a progression is inevitable. It is, however, not infrequent. In many cases it is not difficult to reach the point of diminishing returns with such small 295

2 296 National Computer Conference, 1977 computer systems. The higher-speed peripherals are necessary for adequate time-utilization and efficiencies. Many small laboratories may not be able to purchase the faster more expensive peripherals such as high-speed line-printers or adequately sized high-speed mass storage devices. Be-" cause these peripherals usually facilitate program development, there is the trade-off between increased cost for equipment and increased cost for application software. On the other hand, a centralized facility has the advantage of resource sharing, thereby lessening the utilization cost of expensive sophisticated equipment to anyone user. Qualified personnel can be employed by the central facility and thus be available to the individual laboratories for consultation and other services when needed. Also, maintenance of a central facility can exist within a unified framework under one vendor. However, because of the critical time-constraints which are placed on these applications, one centralized processor may not be able to adequately meet the demand of all real-time needs in a multi-laboratory environment. If many users are competing for high-speed data acquisition capability, some may not receive adequate response from the system. This is of course unacceptable in a real-time situation. A centralized facility could possibly be utilized in a real-time environment only on a demand basis in which a laboratory requests that the highest priority be granted to an upcoming application. However, in the medical environment, the variety of real-time tasks occurring at different times makes scheduling system resources impractical. With many laboratories on-line simultaneously, it is virtually impossible to schedule resources such that each user has access to a specific real-time capability when needed. THE NETWORK APPROACH A compromise between the "in-lab" and centralized concepts is the network approach which offers the combined advantages of both of the above alternatives; that is, the advantages of resource sharing of a centralized system and the speed and responsiveness of a dedicated processor. Through a network, or a distributed computing configuration, a low-cost, memory-only processor can be dedicated to the laboratory to perform critical real-time functions, and through its connection to a host, rely on the host processor's peripherals, bulk storage, high-speed line-printers, etc., when needed. NODAS NODAS is such a distributed computing system. It was designed to help meet the need for a low-cost and highly flexible real-time computing capability for the laboratory environment. It is configured as an "ICDS" (Indirect, Centralized routing, Dedicated path, Star) system 2 or "star" configuration. It utilizes as its host the time-sharing DECsystem-1O and various models of the DEC PDP-II as remote satel1ites, see Figure 1. To the DECsystem-IO host, the remote processor appears to be just an intelligent satellite satellite DECsystem-lO Host Figure I-The NODAS distributed computing network; a star configured network with a DECsystem-lO as a host and PDP-II's as sateljites interactive terminal. Thus as many remote processors can be supported as regular terminals. The remote processor resides in the laboratory and communicates with the host over a "hard-wired" 20-milJiamp loop serial asynchronous line operating at 9600 baud. The usual distance from remote processor to host is from 700 to 1000 feet. Further distances can be achieved using special line-drivers. The system was designed to support a minimal amount of hardware dedicated to any specific laboratory. For example, the minimum configuration for any laboratory satellite is a (whether a PDP or LSI -11) with 8K of memory, 2 asynchronous serial interfaces and an interactive console terminal. One asynchronous interface is used for the console terminal and the other is used for communication with the host. Of course for most laboratory work, an 8 to 16 channel AID converter, a 4 channel DIA converter, and a graphics display device should be included. No mass-storage devices are required for the satellite processor because all program development and data storage occur on the host machine. Programs for the satellite are developed on the DECsystem-1O in a normal time-sharing manner using across-compiler, NODAL (the Network-Oriented Data Acquisition Language), that was written especially for the network system. Load modules are created on the host and sent down-line to be loaded into the remote satellite. The suggested minimal memory size of 8K words is adequate to support programs compiled with NODAL. The remote monitor takes about 500 Bytes and the NODAL run-time package about 3K words. This leaves about 4.5K words for a user program. The 8K configuration has proven to be adequate for a number of small data acquisition and analysis programs. NODAS has two monitors, one which runs on the DECsystem-1O in a time-sharing manner, and the other which is resident within the satellite processor. The monitor in the remote processor allows two modes, Transparent Mode and Execution Mode. In Transparent Mode, the remote user has complete access to the time-sharing facilities of the DECsystem-lO. In this mode, the remote processor merely acts as a buffer relaying bytes of information

3 NODAS 297 from the user to the DECsystem-lO monitor and vice versa. Through Transparent Mode, the user has access to the host to perform data analysis, program development, etc. To achieve Execution Mode, the user runs a submonitor program on the host. Upon entry into that monitor, the name of a particular load module is entered by the user. That module is then sent down-line under a communications protocol and loaded into the remote processor. If the load is successful, execution of the program begins automatically. At this stage real-time activities can be performed. Data can be collected, averaged, displayed, and processed accordingly. Data, once collected, can also be sent back on a non real-time basis to the host for storage and further analysis. At any time during Execution Mode, the remote user can type "Control-C" signaling the resident monitor to return to Transparent Mode. It is interesting to note that to the inexperienced user in the laboratory, the operation of the DECsystem-lO host is more or less hidden. Thus it may appear that the small memory-only PDP-II has all the power of a sophisticated general purpose data-processing machine. As mentioned before, all communications between the host and satellite occur over an asynchronous serial line operating at 9600 baud or less. This baud rate is adequate for most laboratory applications because data transmission back to the host usually takes place in a non time-critical manner. By the time data is sent to the host for storage, the real-time function of collecting, averaging, displaying, and pre-processing has already been accomplished. In many laboratory applications, a great amount of data is collected at high rates and processed in the remote computer creating a final product of relatively few values. Thus data transmission back to the host usually consists of small irregular bursts of data rather than a large contiguous transmission. This is desirable since the transmission of very large data files may be time-consuming and thus interfere with the overall time-sharing response of the host. Although the communication line operates at 9600 baud, the effective transmission rate (observed during operation of the system) is approximately half that or about 500 bytes/ se,cqud, Tb~,s is d.ue in. part tq the cpmiilunic;(iti()n protoc91 overhead, but mainly due to the varying response of the DECsystem-lO time-sharing host. The transmission speed is one limiting factor because some applications may require the rapid collection and immediate storage of data. For these applications, an inexpensive high-speed cassette tape or a small diskette system would be adequate. Actually, an inexpensive form of mass-storage is advisable for certain laboratory functions which must be performed regardless of whether or not the host machine is running. Load modules can be stored on a cassette or diskette and loaded from these devices if the host is not running. Thus a satellite could have enough mass-storage capability to run independently, but not enough to perform the non-time-critical tasks of program development and non-real-time data analysis. The addition of a small inexpensive storage device does not necessarily dilute the advantages of the network configuration. Such an addition could allow the remote processor to be an independent., stand-alone" system with its own operating system. However, the network configuration still has the advantage of allowing the user access to a large time-sharing system with adequate disk space, high-speed alphanumeric input or output devices, and in the case of the DEC system-l 0, software utilities such as a powerful text editor, easy-to-use monitor commands, etc. COMMUNICATIONS PROTOCOL All communications between the host and remote processors occur within the framework of a communications protocol. The protocol is byte oriented and requires the establishment of synchronization between the host and satellite before the communication of each record begins. Each data record begins with a Start-of-Message control byte followed by a byte count and ends with an End-of Message control byte followed by a check sum. Each transmission must be properly acknowledged or a request for re-send will be issued. The protocol is not complex. It was designed for compactness and a reasonable degree of accuracy in a low-noise environment. The protocol establishes the remote processor in a "master" relationship with the host at all times. For example, it is the remote processor that issues synchronization characters when needed and requests that data be sent or that data be received. The host never initiates a request to send or receive data but merely acknowledges the remote processor's requests and acknowledges if a message has been properly sent or received. If an error is detected in a message, it is the satellite that requests to resend or re-receive. Also, if severe "line noise" should result in the processors' losing synchronization, it is the remote processor's task to "time out" and reestablish synchronization. This master relationship of the remote processor simplifies the protocol and allows an adequate degree of control for network procedures. This protocol has been used in a test environment for over a year and in two recent laboratory applications with good results. In a number of testing situations, severe noise wai; ~,QIl tlle se~, cow,w,uaicatioa1il1es with the system ~always recovering without loss of data. The check sum does allow two different one-bit errors in the same relative bit position to go undetected. This has not been a problem thus far. However, future upgraded versions may employ Cyclic Redundancy Checking, CRC-16,3 which perhaps will enhance the error-detecting capability. It must be noted, however, that increased error-checking capability will result in increased overhead. NODAL One of the nice features of NODAS, from a user point of view, is that programs for the remote processor can be easily written in the higher level language NODAL. NO DAL, the Network-Oriented Data Acquisition Language, is similar to FORTRAN and was written especially for the network system. A FORTRAN structure was chosen be-

4 298 National Computer Conference, 1977 cause it is easy to use and perhaps easily recognized by most who have had a little programming experience. This will perhaps encourage laboratory personnel to write their own programs. NODAL is a cross-compiler (which is written in FOR TRAN IV) that runs on the DECsystem-lO in a normal time-sharing manner. Thus programs for the laboratory can be developed outside the laboratory at any time. NODAL has full arithmetic capabilities and has many features of FORTRAN IV. There is a library of callable subroutines that facilitate the implementation of various laboratory and network features. For example, CALL OOPEN and CALL IOPEN which, when executed on the remote processor, direct the host to open a file for remote data storage or retrieval respectively. CALL SEND and CALL RECEIVE will send data from the satellite to the host for storage or direct the host to read a record from its disk and send the data to the remote processor. Thus it is relatively easy for the user to move data over the network. Another interesting aspect of NODAL is the capability for one load module, executing in the remote processor, to initiate the loading of another load module. The CALL CHAIN command will direct the host to load a new program load module down-line and automatically execute it. Thus a sequence of programs can be executed in the remote processor. Data can be preserved in a "COM MON" area, thus allowing communication between these different load modules. One of the most flexible features of NODAL is the ability to place PDP-II assembly language instructions between the higher level language statements. Since the NODAL compiler generates assembly language source, the user written assembly language statement is merely included in the source allowing the user to have complete assembly language capability in manipulating variables defined and used at the higher language level. Some interesting combinations can thus be brought about. For example, assembly language manipulation can direct a vectored interrupt to a routine written entirely in the higher level language. Thus interrupt handlers, device drivers, and other interrupt functions can be written in the higher level language. There are also a number of user system subroutines that will be added to the NODAL library to facilitate common laboratory computing functions. Such routines as SETCLK to set up a real-time programmable clock, SETBUFF to link a buffer with an AID interrupt routine, and various display routines for the support of graphics devices will be available to the user in the NODAS Library. There are a number of interesting minicomputer networks which have been implemented. 4-7 As mentioned before, NODAS uses a "star" configuration. Such a "star" arrangement has the advantage of flexibility and modularity with respect to the remote processors. However, with respect to the hust, tht: "star" arrangement is very inflexible when considering failure-effect and failure-reconfiguration. 8 Therefore, with emphasis on reliability, the NODAS user is given the option of one of two hosts, the DECsystem-IO or a PDP-11145, which is connected to the DECsystem-lO via a DA-28 high speed interprocessor buffer as shown in Figure 2. The PDP-I 1145, running the multitasking operating system RSX-IIM, has two basic functions. The first is to act as a data concentrator for the remote processors thereby increasing throughput to the DECsystem-lO within the network. The second is to act as an independent host if the DECsystem-lO is not running. The PDP-l 1145 can perform all of the host functions except program development. In many respects, from the remote user's viewpoint, there is no difference in being directly connected to the DECsystem-lO or being directly connected to the PDP-Ill 45. The PDP-l 1/45 host can achieve Transparent Mode and allow remote users access to the DECsystem-lO timesharing monitor the same as if that user were directly connected to the DECsystem-lO. However, one major difference does exist between the two hosts. When a remote processor is using the PDP-l1145 as a host, files opened for output by the remote processor will be written on the PDP-I1I45's disk. Therefore the data file must be sent from the PDP-I 1145 over to the proper user's area on the DECsystem-lO in order to be available to the user on a time-sharing basis. EXAMPLE APPLICATION One NODAS application involves the real-time collection of EKG data from the EKG Exercise Laboratory in the Division of Cardiology of The University of Texas Health Science Center at Dallas. The NODAS satellite processor utilized in this application is an 8K PDP-11I20 with 2 asynchronous serial interfaces, an 8 channel AID converter and a 4 channel D/A. This remote processor samples a 3- lead EKG and Phonocardiogram every 5 milliseconds. A Trigger signal is also present (which detects the QRS satellite CONFIGURATIONS PDP-Il r------i DECsystCf:"L~lO PDP- L1!ODP-ll Figure 2-Alternative configuration for the NODAS Network with PDP-III 45 connected to the DEC&ystem-lO via DA-28 interprocessor buffer

5 NODAS 299 complex). Instant graphics feedback is produced with a 4 channel D/A converter driving a Tektronix 611 Storage Scope. During the exercise test, data is sampled for a series of 25-second rest and exercise sessions using different exercise loads. As each waveform is collected, it is examined for proper length and compared, using a correlation routine, with the running averaged waveform. The current waveform is accepted only if the correlation factor is within specified limits. Thus, erroneous waveforms caused by transient noise can be excluded from the final averaged signal. After each 25-second exercise segment, the three EKG waveforms are displayed on the storage scope along with a numeric value representing the heart rate. If acceptable to the operator, the remote processor sends the averaged data to the host for storage and resumes to collect the next 25-second segment. This type of user interaction is typical in the medical laboratory environment and reinforces the need for a responsive computing facility. When the exercise session is finished, the data file is closed on the host and the satellite returns to Transparent Mode allowing the operator access to the DECsystem-lO time-sharing monitor. At this point, the technician can run "non-realtime" data analysis programs on the DECsystem-lO in a regular time-sharing fashion. CONCLUSION The NODAS system exemplifies the use of a distributed computing configuration in establishing a real-time, multilaboratory computing facility for the medical environment. The system is relatively new and is being used at The University of Texas Health Science Center at Dallas. As the use continues, the system will constantly be evaluated and improved. A useful expansion would be the support of the more common micro-processors. The LSI-II is already supported since its instruction set is equivalent to the PDP- 11/40. However, the support for a variety of microproces- sors would increase the utility and value of NODAS. Another area for improvement is in the computer-to-computer communications. Different communication protocols could be evaluated in the attempt to improve transmission efficiency. As mentioned previously, the greatest disadvantage experienced thus far has been the network's sensitivity to hardware failures of the host. However, the addition of inexpensive cassette or diskette storage will help to lessen the dependence on the host during critical real-time activities. The network approach is a valid method for implementing real-time computing capability in a multi-laboratory environment, especially an environment involved in medical research and clinical activities. The distributed-computing approach demonstrates the realization of a laboratory computing facility which offers the speed and responsiveness of a dedicated system while at the same time offering the advantages of resource sharing. REFERENCES I. Saffer. S. I. and D. J. Mishelevich, "A Definition of Real-Time Computing." Comm. ACM (Forum) 18,9 September 1975, pp Anderson. G. A. and E. D. Jensen. "Computer Interconnection Structures: Taxonomy. Characteristics. and Examples." ACM Compo Surv. 7,4, December 1975, pp Boudeau. P. E. and R. F. Steen, "Cyclic Redundancy Checking by Program. AFIPS Proceedings, Vol pp Ashenhurst, R. L. and R. H. Vonderohe, "A Hierarchical Network," Datamation, 21,2, February 1975, pp Farber, D. J., "A Ring Network," Datamation, 21,2, February 1975, pp Wulf, W. and R. Levin, "A Local Network." Datamation, 21,2, February 1975, pp Fraser, A. Goo "A Virtual Channel Network," Datamation, 21.2, February 1975, pp Anderson, G. A. and E. D. Jensen. "Computer Interconnection Structures: Taxonomy, Characteristics, and Examples," ACM Compo Surv. 7,4, December 1975, p. 206.

6