Jun 1, 1993 - instruments, the storage of data gathered by these devices, and ..... Both machines are equipped with Western Digital model ... to test the recovery of these errors from ... can be efficiently implemented in a hard- ware/software ...
An Implementation of the IEEE Medica Information Bus Standard T
he IEEE P1073 family of documents defines the Medical Information Bus (MIB), which is basically a local area network for the bidirectional interconnection of medical devices and computers. This network is intended to aid in the registering of information such a s alarms from medical instruments, the storage of data gathered by these devices, and their control from a central computer. The standardization process initiated by the IEEE PI073 Medical Information Bus
Carlos H. Salvador Nicanor Pulido Jose A. Quiles Miguel A. Gonzalez Bioengineering lab Hospital Puerto de Hierro Madrid
(MIB) Committee for the vumose of receiving signals from the patient environment in intensive care or similar units has been greeted with enormous interest on the part of engineers and physicians involved in this area [l, 21. In this network, there are three types of controllers, BCC BCC BCC as described below: The Device Communications Controller (DCC) is the entity associated with each medical device; its principal functions are to send data from the device to the system and iiost receive orders from the host com3cc puter. w The Bedside Communications , ." , ",> Controller (BCC) is associated DCC DCC with each bed or patient. Its most rei c e cc important functions are to detect the connection of a DCC, direct the messages from the host to the proper device, supply power for the hardware of each DCC, and detect failures in communications with the devices. Each DCC is associated with a single BCC, and each BCC is associated with a bed, although each bed may have several associated BCCs. The MIB Communications Controller (MCC) is the component associated with the host. Its I main functions are to receive the 1. Different topologies for the MIB information being transmitted by a) Each BCC is associated with a single bed, although each bed may have several corresponding the devices, spontaneously or on BCCs. The topology of the intra-bed network is in command, and also to control these devices. the form of a star. Figure 1 presents Some examb) Each bed has its own host which performs the ples of Placement of the entities functions of the BCC. The inter-bed network is described and the different topolonot necessary. gies that the network can adopt. c) Each bed is an intelligent device which functions like a BCC-controlling other devices-in a Figure la, which illustrates the subnets involved in the MIB (the intramanner which is transparent to the host. I
_
I
1.P"
June 1993
I
IEEE ENGINEERING IN MEDICINE AND BIOLOGY
bed and inter-bed networks) is the most common configuration. The intra-bed network has a star-shaped topology and the BCC, or main station, polls all its ports, whether connected or not, in round-robin fashion with a frequency between 1 and 10 Hz. This network does not require a great capacity (hundreds of kbls) although it must be easily reconfigurable given the many device connections and disconnections that may occur. The inter-bed network links all the beds to the host. This network requires a wide bandwidth and a low error rate, due to the high traffic level.
Technical Description The Medical Information Bus (MIB) described in the IEEE P1073 family of standa r d s , follows the Open Systems Interconnection Basic Reference Model (OSI/RM) [3] of the International Standards Organization (ISO). This set of standards is divided into four major document types, each of which describes a part of the MIB. The different layers of the model and their relation to the documents (which are de. scribed below) can be seen in Fig 2.
Documents P1073 The purpose of this document is to provide the overall definition of the family of standards. This document defines the conceptual and information models for medical device communications and specifies constraints for compliance with the set of standards. P1073.1.x These documents define the semantics and syntax of information interchanged between medical devices and host computers. For this purpose, the Medical Device Data Language (MDDL) is defined, to allow data provided by instruments from different manufacturers to be understood by the central host. P1073.2.x This set of documents specifies the base standards for use in the upper layers of the OS1 model: Application, Presentation, and Session. The session layer is described by I S 0 Session, which is capable of establishing connections (sessions) and transmitting data through them in an orderly fashion. The presentation layer is defined in the 0739-5175/93/$3.0001993
81
I
P1073.3.1 standard [4] defines the interconnection between the BCC and the DCC (intra-bed network). The technical description of the layers is as follows: In the physical layer, the RS485 standard [5] is used, with a non-return to zero inverted (NRZI) line code at 375 Kbls, which provides high noise immunity and large capacity. A six-pin connector is specified: two for half-duplex transmission-recep1073.3.2 1073.3.1 tion, two to supply power for the communication hardware of the DCC and the remaining two for 2. The network and the relation with the OS1 model, the components DCC, BCC and MCC and time-synchronization pulses. In the data link layer, a subset of the the intra-bed and inter-bed networks. two-way alternate Normal Response Mode (NRM) of the HighX.409 standard of the Comit6 Consultatif level Data Link Control (HDLC) protocol International de TMgraphique et T616phon- [6] is employed, which guarantees packet ique (CCI'IT); it consists of an abstract syn- integrity and sequential arrival, avoids dutax in which the types of data are defined, plication, corrects errors by Cyclic Redunand a transfer syntax in which the banner in dancy Code (CRC), and has a roll-call which each type of data is transmitted is polling mechanism. This layer provides the specified. The application layer uses stand- primitives for a connection-oriented service ard Application Service Elements (ASEs) with point-to-point data transfer. Although for the Association Control Service Element the network and transport layers are func(ACSE) for establishing and releiising con- tionally inactive, they provide primitives for nections and the Remote Operations Service connection, data transfer and disconnection. Element (ROSE) for defining remote operaThe P1073.3.2 describes the transport tions. Moreover, a specific ASE, deferred to layer connection between the MCC and the as the Medical Device Application Service BCCs (inter-bed network) over a convenElement (MDASE), is defined. The basic tional Local Area Network (LAN) using component of MDASE is the Medical De- TCP/IP [7] protocols for the transport and vice Data Language (MDDL). network layers. P1073.3.x The rest of the P1073.3.3-6 documents These documents describe the four lower are still pending approval, but the P1073 layers of the OS1 stack transport, network, Committee intends to associate each one data-link, and physical. In particular, the with a 802.x LAN standard [8]. 1073.1 1073.2.X
Proposal MIB Instrumentation
Non-MIB Instrumtation
rd
I
I
PC
Ettmmet
3. BCC which supports MIB devices and non-MIB devices. These are connected to the PC by means of an acquisition board.
Once the MIB document is approved, three initial design considerations will have been assumed, and the aim of our work is to achieve a satisfactory response to them: 1) A transition period will be necessary (its duration will depend on technological, commercial and legal factors) during which MIB devices (with DCC incorporated) and non-MIB devices (without DCC) will coexist in patient care and monitoring environments. Our response is to implement a BCC which admits both types of devices. The DCCs of the non-MLB devices are implemented by means of software in the same machine. Other parts of the acquisition unit, not described here, will perform the necessary digitization and processing, leaving the results in certain memory positions, where they will be retrieved by simulated DCCs. The MIB devices will be connected by a serial port, as shown in Fig. 3.
IEEE ENGINEERING IN MEDICINEAN0 BIOLOGY
2) To accomplish the greatest possible diffusion and acceptance, the practical implementations must be simple, and the basic hardware/softwaremust be readily available and of low cost. Our approach is to create the four lower layers of the intra-bed network (P1073.3.1), starting with apopularpersonal computer with MS-DOS operating system. We do not discuss here which topology of those seen earlier is the most convenient, nor the external aspect of the BCC. 3) For the implementation of the interbed network (P1073.3.2), the BCC has been connected to a UNIX machine that serves as an MCC via an Ethernet network and TCP/IP. UNIX was chosen as a support for the MCC because of the need for apowerful operating system, capable of managing processes, timers, and a very extensive memory. It should be taken into account that there may be several BCCs and that the MCC must establish connections with each, of the DCCs that have associated BCCs.
Implementation of the Intra-Bed Network: Auxiliary Software Once the computer and operating system are chosen, several problems arise. The major one is that MS-DOS is a mono-task operating system, which executes its tasks sequentially. To give the reader an idea of the extent of this limitation, consider a communications program, the most important tasks of which are to send and receive data packets. The process of transmitting data is not complicated, since the transmission occurs in an instant that is completely controlled by the program being run.However, the task of message reception involves a different concept. The pseudocode of a process for message reception would be something like: do ifthere are data then read data forever It is not difficultto encode this pseudocode using MS-DOS, butaparticularconcerna&es. Until this program is terminated, no other program can be executed, i.e., this program never ends. The processor is monopolized exclusively for the reception of messages. Thus, it is necessary to create a process manager which allows MS-DOS to handle concurrent tasks, such as UNIX or another multitasking operating system.On the other hand, all communications software is based on timersand operates on data packets. Thus, it is also necessary to use a timer manager and a memory manager as auxiliary software.
Process Manager The process manager created is nonpreemptive: when a task controls the CPU, it is not interrupted until the process manager June 1993
decides to for any of several reasons. Normally, a process is suspended when it awaits some event and does not awaken until said event occurs. A process can be in one of the following states: W Running: State of the process (only one) which controls the CPU. Ready: State of those processes which, not being executed, are temporally detained and can be executed at any time. W Waiting: State of those processes that cannot be executed until some external event takes place, such as a timer going off, the arrival of incoming data, etc. There are two basic primitives to change the state of the processes: W wait(): The process suspends its execution to wait for an event, which is specified upon use of this primitive. signal(): Signals that a certain event has occurred, and specifies its nature. With these two primitives, an entire system of processes is constructed and is executed in concurrence in a MS-DOS computer. The wait() primitive is called by the same process to enter a state of expectation; the signal() primitive is called by the other process once the event occurs. Typical examples of events for which a process might wait are a keystroke, the arrival of a data packet, a timeout, etc.
Timer Manager When a resident process in one machine communicates with another resident process in a remote machine, the former can not suppose that the remote process is always going to respond; there could be a communications failure that would hang the arnval of the question and/or reply. For this reason, when a message is sent to the other process, a timer is started by the transmitter process. If the response does not arrive at all, the timer reaches zero, and the process is set off by the timer, which signals the existence of a failure. Therefore, it is necessary to create a timer manager that permits the simple and efficient management of timeouts by the processes When a timeout occurs, the signal() primitive of the process manager awakens the process that started the timer. This manager is provided with one primitive to start a timer with a preset deadline, expressed in milliseconds (the precision is 55 ms, imposed by the PC hardware) and another to stop a running timer.
packet are common in this type of software. Thus, a manager of buffers, queues, and packets has been created to perform these and other operations.
OS1 Software For the implementation of the different layers of the OS1 tower, the following philosophy has been applied: each OS1 layertransport, network, etc.-is a process that may be in a certain STATE and is waiting for an EVENT to be produced. Depending on the nature of this event, the process will
enum (DISCONNECT, CONNECT, DATA) DCC-Tran-state: int DCC-TranSignal: void DCC-tran (void) ( f o r ( ; :)
I switch (DCC-Tran-State) case DISCONNECT: wait (&DCC-TranSignal); if( DCC-Tran-Signul= = DCC-tran-connect-req)
I DCC-Net-Connect-req(); DCC-Tran-State = CONNECT;
I else DCC-Tran-Disconnect-ind(): DCC-Tran-Stute = DISCONNECT:
I break; case CONNECT: I*
Memory Buffer Manager Communications software must frequently manage data packets. Operations such as adding a header, extracting the last byte, or calculating the length of a data June 1993
change from one STATE to another and carry out given ACTIONS. The framework described here is adapted to the finite state machine (FSM) model, with a series of STATES, possible INPUTS (or events), OUTPUTS (or actions) and TRANSITIONS between states. To clarify these concepts, the application of this model to a specific example, as is the DCC transport layer, will be presented. This layer was chosen because the diagram of its states is very simple, and our aim here is to explain how this diagram can be encoded in the form of a process. Figure 4 shows that the layer can be found in any one of the following states: DISCONNECT, CONNECT or DATA. If we focus on the DISCONNECT state, we see that either a connection request, DCC-Tran-Connect-req(), or some other EVENT is produced. In the first case, the ACTION to be taken consists of mapping the connection request over the next lower l a y e r , c a l l i n g t h e DCC-Net-Connect-req() primitive. The process then passes to the next state, or CONNECT. In the second case, the ACTION is to invoke the DCC-Tran-Disconnect-ind() primitive, and the following state, DISCONNECT, remains unchanged, that is there is no transition. For the other states, the description is analogous, except that their possible inputs and transitions differ. The encoding of this diagram, making use of the process manager primitives described in the preceding section, is shown below:
... *I
case DATA: I*
... *I
I 1
IEEE ENGINEERING IN MEDICINE AND BIOLOGY
a3
DCC-Tran-Connect-reg
1 DCC-Net-Connect-req
_ ,
I
-_ ---1
other !
CONNECT
1I ,
\.. ._ DCC-Tran_DiSconnect-req
/ DCC-Net-Disconnect-req
DCC-Net-Disconnect-ind 1 DCC-Tran-Disconnect-ind other I DCC-Tran-Disconnect-ind
,I
't
DCC-Net-Data-ind && Header!=O !',sDCC-Tran-Disconnect-ind DCC-Tran-Disconnect-req ! ACC-Net-Disconnect-req DCC-Net-Disconnect-ind ! %C-Tran-Disconnect-ind
DCC-Tran-Data-req ! KC-Net-Data-res DCC-Net-Data-ind && Header==O ! DCC-Tran-Data-ind
4. State diagram of DCC transport layer to illustrate how protocols are implemented.
5. Simplifiedstate diagram of BCC link layer to show the polling mechanism.
84
IEEE ENGINEERING IN MEDICINE AND BIOLOGY
f
1
1
BCC-Link-Con
1
ec-resp
I
1 DCC*onnect-conf
other. Each layer has two reserved buffers: one for the packets from the next higher layer destined to the network, and the other for packets from the preceding layer destined for the user. For the construction of the data packets corresponding to each layer, adding headings, extracting them, etc., the functions of the buffer manager, which manages linked data structures, have been used.
Physical Layer 6. Connection mechanism with the associated HDLC frames interchange.
MCC
BCC
I 1 I TCP/I P
TCP/IP
LLC(driver)
Process Manager
WD8003E
it-
1
I
WD8003E
Ethernet 7. Implementation of the inter-bed network with the machines involved in this network. Of the two variables, one, referred to as DCC-Tran-State, as its name indicates, stores the state of the transport layer. The other, DCC-Tran-Signal, indicates what event has been produced. The process of the transport layer is an infinite loop and, depending on the value of the state variable, the code corresponding to the present STATE will b e executed. For every DCC-Tran-State value, the process calls the primitive wait(&DCC-Tran-SignaI), transferring control to the process manager, and awaits the signalling of some event. When the e v e n t is produced, a signal(&DCC-Tran-Signal) is invoked, and the process of the transport layer proceeds to follow the next instruction. By examining the contents of the DCC-Tran-Signal variable, it is possible to determine the event that triggered the process and proceed according to its value.
Primitives The I S 0 OS1 standard stipulates that the service offered by one layer to the next is specified by the service primitives. In the
June 1993
As has been noted in the introduction, since the DCCs associated with medical devices do not yet exist, they have been simulated by software, and reside in the same machine as the BCC. Thus, the data exchanged between the BCC and the DCC does not leave the machine, but circulates via the internal bus. When the Phys-Data-req() primitive is invoked, it merely copies data into the preallocated space of the adjacent physical layer, and awakens it by means of the Phys-Data-ind() primitive. Once future MIB devices are integrated, the remainder of the layers will continue to be valid, requiring no adaptation. In the physical layer, some modifications will be required. When a Phys-Data-req() is produced, the packet will be transferred to the communications board, which will transmit the data, instead of copying it directly into the other physical layer as is done at present. The Phys-Data-ind() will be produced by a hardware interrupt once the data is received via the RS- 485; that is, the signal() of the physical layer will produce an interrupt routine, rather than the adjacent physical layer, as now occurs.
network implemented here, there are primitives for connection, disconnection, and data transfer. These primitives have been set up in the form of functions, and the way they are implemented is explained below. When invoked, the connection and disconnection primitives awaken the proper layer, calling the signal function of the process manager and indicating which primitive w a s the trigger. F o r example, the DCC-Tran-Connect-req() primitive has been encoded as follows: #dejne DCC_trunpconnect-req 141 void DCC-Tmn-Connect-req (void)
I DCC-TrariSignal= DCC-tran-connect-req; signal (&DCC-TranSignul);
J The DCC-Tran-Signal variable is assigned the DCC-tran-connect-req value so that, when awakened, the transport layer is aware that the event produced was a Connect Request. The data transfer primitives operate similarly, differing in that, in addition, they copy data packets from one adjacent layer to anIEEE ENGINEERING I N MEOKINE AND BIOLOGY
Data Link Layer The data link layer is the main layer of the intrabed network, guaranteeing that the data packets are transmitted without error to the other end of the line by means of a STOP and WAIT protocol. The packets, in agreement with the High-level Data Link Control (HDLC) frame structure specification [9], include a Cyclic Redundancy Code (CRC) field, which serves to determine whether the packet has been received free of errors. Moreover, the packets are numbered, which serves to indicate to the other end whether or not the packet has been correctly received, and if not, or there is a gap detected in the sequence of received packets, the retransmission of a given packet can be requested. As previously mentioned, in the data link layer, a subset of the Normal Response Mode (NRM) of HDLC is employed. In this mode, there is a main station, which in the MIB is the BCC, and one or more secondary stations, here the DCCs. The main station 05
carries the initiative in the protocol, being able either to transmit data to any DCC, or invite any DCC to send data to it by means of a polling mechanism. The P1073.3.1 document establishes the frequency of this polling at 1 to 10 Hz. Figure 5, a greatly simplified diagram of the states of the BCC data link layer, illustrates this polling mechanism. Each time the BCC reaches the CONNECTED POLL state, it starts a timer with the polling interval of 100 ms to 1 s, and relinquishes control, remaining in wait(). When the polling interval expires, the data link layer of the BCC is activated by the process manager and proceeds to the polling. If the BCC has data pending transmission, it sends the data with a type I frame, inviting the DCC to reply. If the BCC has tlo data, it polls the DCC with an RR frame if it is prepared to receive data, or with an RNR frame if it is not. The BCC goes to the DATA POLL RESPONSE state to await a reply from the DCC, which can be a I frame-with information-an RR frame or an RNR frame. If none of the preceding ftames are received, a timer set for this purpose awakens the BCC, and in either of the two cases-the reception of a protocol or the timer going off-the system proceeds to the CONNECTED POLL state to initiate another polling. T o establish connections, a polling mechanism similar to that described for data exchange is used. The BCC polls the disconnected DCCs, inviting them, via XID frames, to connect themselves, again at a cadence of from 1 to 10 Hz. When the DCC is connected, it responds with another XID protocol. The exchange of signals and frames is illustrated in Fig. 6, with the form of the transitions shown in Fig. 5. As mentioned above, the protocol implemented is of the STOP AND WAIT type. That is, a second packet is not sent until confirmation of the preceding one is received. For this purpose, a buffer space has been designated for packets pending transmission. The packets are stored in h e buffer when a Link-Data-reqO is received, and released when the other end c o n f i i s that the packets have been correctly received. In this way, the loss of packets, which could occur if in the time it takes to c o n f i i a frame one or more requests for transmission are received, is avoided.
Network and Transport Layers The network and transport layers are functionally inactive. Although chey have their own primitives, their only taskis to map these primitives over the lower layer or transfer them to the upper one. For example, upon receiving a Tran-Data-req(), the transport layer calls the equivalent primitive of the network layer: Net-Data-req(). Like86
wise, the BCC network layer, upon receiving a Link-Connect-resp(), calls the Net-Connect-resp() primitive.
Implementationof the Inter-Bed Network The purpose of the inter-bed network is to link the existing BCCs to a central station which, according to the MIB terminology, is referred to as the MCC. This central station receives the data transmitted from the different medical instruments connected via the inter-bed network. The control of the devices can also be done from the MCC, which transmits commands to the respective BCC, which signals the corresponding DCC. The network has been physically implemented with an Ethernet, as can be seen in Fig. 7, and links the MCC (a personal computer with the UNIX operating system) with the BCC (a personal computer with the MSDOS operating system). Both machines are equipped with Western Digital model WD8003E Ethernet controller cards. The connection between the BCC and the MCC is done via TCP/IP, as specified by the P1073.3.2. The portion of the software corresponding to the MCC uses the socket interface provided by the UNIX operating system [7]. Expressed in terms of the client-server model, the MCC would be a server attending to the requests for connection from a group of clients (BCCs). For each request, a TCP connection is established, and the processes in charge of receiving and sending data via said connection are created-by means of the UNIX fork() system call. When a server has finished attending to a client, it remains in a state of preparedness to attend to another, carrying out the same series of actions for each new connection request. To create the portion that resides in the BCC, it was necessary to base all the software on the previously described process and timer managers (it must be remembered that the BCC works with MS-DOS). For this purpose, a TCPnP implementation for personal computers, known as the KA9Q Internet Package, developed by Phil Karn [101, was adapted to function with the previously described process manager. Basically, the absolutely necessary modules of TCP/IP were taken (given the memory limitations imposed by the MS-DOS) and the function calls were substituted with equivalent ones developed by us. A driver for the Ethernet controller card was developed, corresponding to the Logical Link (LLC) sublayer of the Data-Link layer [8]. In writing this driver, it was necessary to fulfill two conditions: on the one hand, it would have to adapt to the TCP/IP implementation used, that is, construct the funcIEEE ENGINEERING IN MEDICINE AND BIOLOGY
tions called by the IP module for transmission and receiving of data; and on the other hand, it would have to be able to integrate with the rest of the resident software in the BCC, making use of the process manager. More specifically, a routine has been written in assembly language which manages the interrupts produced by the controller card. There are two types of interrupts, one occurring when a data package arrives and the other when the card is ready to transmit. When the card receives data, they are stored provisionally in the memory of the card itself. Then, the interrupt routine copies them into the system memory and transmits the necessary commands to allow a repeated reception. Data to be sent are left in a queue of packages waiting for transmission, and when the card is ready to transmit, it is the interrupt routine that takes those that have been waiting the longest and, after adding the Ethernet heading, copies them into the card memory and sends the command to transmit to the card. Additional functions have been developed to initialize the card and register the network statistics.
Test Performance To assess the performance of the implementation, a test was designed consisting of nine simulated DCCs (that represent the different signals received in the real monitoring case described below). The BCC is formed by nine groups of processes, one for each DCC. Each group is made up of the processes of the different layers. The data link layer of each of these groups is that which polls the associated DCC. A polling interval of 100 ms was established, corresponding to the strictest requirement (10 Hz) proposed by the document. For each DCC, the BCC establishes a connection with the MCC in a TCP port. The physical layers of the DCCs and the BCC have been implemented in such a way that errors are introduced into the frames to test the recovery with a probability of of these errors from the data link layer onward. On the top of the DCCs, user processes have been implemented to transmit data to the other end. Each DCC sends a 100-byte frame at a variable interval ranging between 1 and 10 s. The MCC sends 100-byte frames at intervals of 1 to 60 s. Obviously, this interval is greater than the send interval because the devices generally produce much more information than they receive. The adjustment of the parameters is done sporadically, while the DCCs are continually acquiring information to transmit. Table 1 shows the results corresponding to one hour of simulation. The BCC and nine simulated DCCs were tested in 12 MHz i286 June 1993
(model ARC PT-286e) and 16 Mhz i386SX (model ARC PT-386sx) computers. The MCC was a 25 MHz i386 (model HP Vectra RS/25C). The table includes the number of polls produced, as well as the number of frames exchanged in each direction by each device. By dividing the total number of polls among the nine DCCs and the total trial time, a rate of 6.3 and 7.6 polls per device per second is obtained for each of the machines mentioned above, which fulfills the condition proposed by the P1073.3.1 document. The total amount of data transmitted is 734 and 764 kbytes; thus, in each of the DCC connections, the mean rate of exchange is 23 and 24 byte&. In view of these results, it can be concluded that the performance of the implementation is totally satisfactory.
I
Table 1. Test Performance Number of polls
Frames from MCC
Frames from DCC
i286
to i286
i286
i386SX
22,744
27,210
Connection 2
22,643
27,332
Connection 3
22,689
27,275
Connection 4
22,639
27,464
Connection 5
22,759
Connection 6
22,651
Connection 7
22,794
Connection 8
22,656
~
to i386SX
i386SX
72
73
725
785
156
90
733
753
27,450
101
126
717
769
27,379
85
103
725
756
27,377
72
132
735
27,449
133
109
700
I
I
746 704
Real Monitoring Case The first real application of the MIB implementation consisted of its inclusion in a unit for the acquisition and processing of physiological signals from patients with intracranial hypertension. The signals monitored-AP (arterial pressure), E C G (electrocardiogram), Paw (airway pressure), ICP (intracranial pressure) (2), CP (cardiac pulse), BF (blood flow) (2) and CVP (central venous pressure)-are shown with the results of their processing in Table 2. This set of signals appears in the monitoring protocol for an experimental study in ICP monitoring, a field of research for which our group has ample experience [ 111. Obviously, in patient ICP monitoring, the signals processed and the results calculated are fewer. In fact, some of the above are not included in the list of expected parameters for the MIB document. The physiological signals are picked up by an acquisition board, which digitizes them at 100 Hz (AP, ECG, ICP, BF) and 25 Hz (Paw, CP) sampling rates. The data are then processed, and the results are loaded into the main memory of the PC in which the DCCs are being implemented. A simulated DCC has been created for each of the nine signals monitored; in this application, all the devices are non-MIB. As shown in Table 2, results are obtained at 10 or 60 s intervals. The DCC corresponding to each signal knows the memory position in which the acquisition and processing card deposits these results. Thus, it is merely a question of picking up the results and sending them to the BCC by means of the DCC-Tran-Data-req() primitive of the transport layer.
Conclusions Our main conclusion is that P1073.3.x can be efficiently implemented in a hardware/software set-up as popular and ecoJune 1993
Table 2. Application: Signals and Results Signal
each10seconds
each 6O'seconds
Arterial blood pressure
Mean value, mmHg Systolic, mmHg Diastolic Pulse wave amplitude, mmHg Heart rate (trigger from ABP), beats/min
Arterial pulse wave average
ECG
Heat?rate, beats/min
Epidural intercranial pressure (two)
Mean value, mmHg Cerebral pulse wave amplitude, mmHg Cardiac pulse wave amplitude, mmHg Respiratory pulse wave amplitude, mmHg
Airway pressure
Mean value, cm H20 Peek, cm H20 Baseline, cm H20 Breath rate (trigger from Paw), breaths/min
Cardiac pulse
Pulse rate, beats/min
Central venous pressure
Mean value, mmHg
Blood flow' (two)
Mean value, Vmin Pulse wave amplitude
Cardiac pulse wave average Respiratory pulse wave average
~
*Electromagneticflowmeter. Only experimental monitoring
nomical as a personal computer. It can be integrated with software that performs other functions-acquisition and processing of the signals picked up-without the emergence of performance problems worthy of mention, even in an experimental environment that is much more demanding than the IEEE ENGINEERING IN MEDICINE AND BIOLOGY
monitoring of patients in a clinical environment. In view of the good results, the communications software is presently being integrated into all of the functions of the monitoring unit, mainly with the software for real-time storage of samples and their 87
I
I
graphic display. The storage task occupies a great amount of CPU time, since real-time storage is of a very high priority, even higher than that of communications software. On the other hand, the time consumed depends on the disk model, the number of files open at any one time, and other factors which deviate somewhat from the purpose of this work. Nevertheless, any future modification in the implementation of the document which introduces an improvement in performance is welcome. Our suggestion is to eliminate the network and transport layers of the intra-bed network, since they are inactive. The user of the network would employ the transport layer primitives, but these would correspond exactly to those of the data linklayer. The savings that the headings previously introduced by the eliminated layers would now be introduced by the routine which constructs the HDLC hama. Thus, an implementation is achieved in which the imterfaces at the transport and physical layers fulfill the specifications of the document, although internally the structure has been notably simplified.
Acknowledgement The authors wish to thank D.F. Franklin (Southern College of Technology, 1112 Clay Street, Marietta, GA 30060) for kindly sending us the initial information regarding the IEEE P1073 Committee, F. del Pozo for his suggestions regarding the design, and Dr. Garcia de Sola for his help in the real monitoring case. Likewise, we wish to thank M. Messman for her translation of the manuscript. This project is being funded in its entirety by the Fondo de Investigaciones Sanitarias de la Seguridad Social, Spain (FIS grant no. 89/098-2).
Carlos H. Salvador received his degree as a telecommunications engineer from the Polytechnical University of Madrid in 1976. Since then, he has been involved in research in the Service of Experimental
Surgery of Hospital Puerta de Hierro in Madrid, dealing mainly with surgery for cardiac arrhythmias and intracranial pressure monitoring. Currently, he is chief of the Bioengineering Laboratory at this hospital. His interests focus on the design of instruments based on personal computers and the use of the ISDN for communications among health care users. He is now participating in the European RACE Programme (Project R.1042 MultiMed). He can be reached at Laboratorio de Bioingenieria Hospital Puerta de Hierro, G/ San Marth de Porres, 4 28035 Madrid, Spain; Fax: 34-1-373 7667 Nicanor Pulido, sixthyear student of telecommunications engineering at the Polytechnical University of Madrid, has been a fellow in the Bioengineering Laboratory of Hospital Puerta de Hierro in Madrid since October of 1990. He is currently participating in a project dealing with units for signal acquisition in the intensive care environment. Jose A. Quiles graduated from the Polytechnical University of Madrid as a telecommunications engineer in 1990. Since 1988, he has been working in the Bioengineeri n g L a b o r a t o r y of Hospital Puerta de Hierro, dealing with the design of acquisition, processing and storage subsystems for intracranial pressure (ICP) monitoring using integrated microcontrollers and based on personal computers and UNIX workstations.
Miguel A. Gonzalez received a degree as an industrial electronic master, granted by Santa Ana y San Rafael Industrial Master’s School, in 1972. Between 1975 and 1979, he worked in the Maintenance Service of Hos-
IEEE ENGINEERING IN MEDICINE AND BIOLOGY ~-
pital Puerta de Hierro in the Electronics Department. In 1979, he began to work in the Bioengineering Laboratory, devoting himself to the design and development of instruments based on microprocessors. At present, he focuses on multimedia workstations for use by medical professionals. He is now participating in the European Race programme (Project R.1042 MultiMed).
Refecences 1. Franklin DF, Ostler DV: The p1073 medical informationbus. IEEE Micro 9: 52-60, 1989. 2. Nolan-AvilaLS: Uses and benefitsof the medical information bus. IEEE EMBS Ninth Ann Int Conf: 1211-1212, 1987. 3 . IS0 7498: Information Processing SystemsOpen Systems Interconnection-Basic Reference Model. International Standards Organization,
1984. 4. IEEE P1073: Bedside Communications Subnet, Draft 14, IEEE, 1991. 5 . EIA 485: Standard for Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems. Electronics
Industries Association, 1982. 6. IS0 4335: Information Processing SystemsData CommunicationHigh-Level Data Link Control Procedures-Consolidation of Elements of Procedures. International Organizationfor Stan-
darization, 1987. 7. Comer DE: Internetworking with TCP/IP Vol I, 2nd Ed, Prentice-HallInternational, 1991. 8. TanenbaurnAS: Computer Networks, 2nd Ed, Prentice Hall International,pp 141-265,1989. 9. IS0 3309: Information Processing SystemsData CommunicationHigh-Level Data Link Control Procedures-Frame Structure. International
StandardsOrganization,1991. 10. Karn P wsmr-simtel2O.army.mil.directory: PD3:.Available as Internet softwarepackage. Accessiblevia anonymousftp. 11. Garcia-Sola R, Vaquero J, Cabezudo J, Bravo G: Evolution of intracranial and cerebral blood flow in cryogeniccerebraledema.Intracranial Pressure N . Shulman, K. et al., SpnngerVerlag, New York, pp 268-271, 1980.
June 1993
