A FPGA
based Implementation of an Intravenous Infusion Controller System
Cristiano C. de Araújo , Marcus V. D.
dos Santos and Edna Barros
Depto. de Informática - UFPE
Caixa Postal 7851 - Cidade Universitária
CEP. 50740-940 Recife - PE - Brazil
{cca2, mvds, ensb}@di.ufpe.br
Abstract
In this paper we present the
development and implementation of an intravenous infusion controller
system based on fpga´s. The system receives information of an
infusion drop sensor and controls the drop flow by giving the
direction and number of steps of a stepper motor, which compress
the drip-feed hose. The system consists of a mixed implementation
of software and hardware. The software was implemented in C++ and
the hardware was implemented by using FPGA´s.
1 - Introduction
The aim of this work is the development and implementation of a system to control the flow of an intravenous infusion gravity system. Such kind of infusion system is the simplest and cheapest, but the infusion rate can vary with the volume to be infused. In order to keep the infusion rate constant, the drip-feed must be adjusted. In the most cases this adjust is done manually, which implies that someone must take care all the time in order to keep constant the infusion flow and to prevent some situations like: the end of infusion is reached, the sensor does not function, the drip chamber is obstructed. In the case where the patient receive medicine or nutrition through the infusion (e.g. parenteral feed), this kind of monitoring can become critical, since the absorption, in this case, depends on the accuracy of the infusion rate. Additionally, the manually monitoring of a large numbers of patients can lead to a stressful work environment. All these facts state the need of an automatic monitoring system, which should keep the infusion flow rate constant and should be able to signal when something is wrong. An automatic monitoring would be very helpful in order to guarantee a safe and accurate infusion process.
The main aim of this work is the
development of a control system for a gravity infusion system.
The system consists of a board, which can be connected to some
personal computer (486 or Pentium). This feature makes the system
very useful for home IV infusion therapy.
An infusion controller has been
implemented by Ferraz [Ferraz-93] and another one has being developed
at the department of biophysics in our university. The first one
was implemented in software and has used a DC motor for pressing
the drip-feed hose. The second one has being implemented in discrete
hardware and is using a stepper motor. The proposed work has been implemented
in hardware and software and has used also a stepper motor for
pressing the drip-feed hose. As it will be seen later, the
proposed system is faster than the first one and more flexible
and has more scalability than the second one. Another feature of
the proposed work is the hardware implementation by using the
fpga technology, which allows the implementation of a first
prototype in a very short time and at low cost.
This paper is organized as follow: in the next section an overview of an intravenous gravity infusion controller system is presented. After that, some background in the FPGA technology and in the design of digital systems by using CAD tools is given. The implementation of the intravenous infusion controller system, proposed in this work, is detailed in section 4. First, the software implementation is described. After that, the developed hardware is described followed by the description of the implemented hardware/software interface. This section is finished with the presentation of some results based on experimental measurements obtained by using a first prototype of the proposed controller. The paper is concluded by giving some comments and perspective for future works.
2 - The Intravenous Infusion Controller System - IVICS: An Overview
The Intravenous Infusion
Controller System - IVICS- is a single patient control system ,
which controls the intravenous infusion of serum (in drops/min.)
and the infused serum volume (ml), and sends messages when
something wrong is happening. The IVICS system aims to keep
constant the serum flow between values going from 4 up to 80
drop/minute, with a dynamic maximum error of 1 drop/minute. Using
a personal computer, the operator gives the proper dosing rate ,
the volume to be infused and the used kind of drip-feed unit.
After the input data has been given , the monitoring can be started and
the desired flow will be kept constant while no error event
happens.
As it can be seen
in the figure 2.1, the IVICS system is a closed-loop control
system, which measures the time interval between successive drops
falling through the drip-feed unit and correct the flow by
actuating on a stepper motor, which compress or decompress the
drip-feed hose. The flow rate, pre-defined by the operator, is
converted to time value (desired time between drops) and the flow
is measured by taking the time value (magnitude). The measured
time between two drops is compared with the desired time between
drops and the system activates a stepper motor in order to
correct the error, if necessary.
Figure 2.1 - The
IV Infusion Controller System - IVICS
The optical sensor has a infra-red LED (light emitter diode) and a photo-transistor which sends 1 (drop) or 0 ( no drop) to the hardware. The computer receives the drop data, calculates the error and the number of steps for correct it by applying distinct algorithms and sends to the hardware a 8-bits instruction informing the direction and number of steps. The IVICS hardware receives this information and converts it in pulses and signals for the stepper motor. The IVICS hardware communicates with the computer ( software ) by using a proper protocol. The hardware receives a 8-bits instruction and a start signal to convert the 8-bits instruction in 0 up to 127 pulses sequence and sent it to stepper motor. The patient button is a push button that send 1 ( patient ready to be infused ) or 0 (patient not ready) to the FPGA Hardware.
For the sake of simplicity, the
communication between the hardware and the personal computer has been
implemented by using the "Centronics" parallel port (
I/O addresses 378h, 379h and 37ah ).
The IVICS system control logic
uses four distinct algorithms for error correction depending on
the error value and on the flow range. The flow range ( from 4 up
to 80 drops/min.) has been divided in five rate regions due to
non-linear pulses response ( the system behavior for high rates
is different than the behavior for small rate values)
[Ferraz-93].
When the error is greater than 1
drop/min and smaller than some tolerance value, the used
algorithm is the called "Bang-bang" algorithm, which
keeps the error in 1 drop/min. The pre-control algorithm is called
for negative error values and the post-control algorithm corrects
errors greater than the tolerance value. When the measured flow
value is in a distinct region than the desired flow, the range control algorithm
is executed. More details about these algorithms will be given in section
4.1.3.
The IVICS system has also a fault
tolerance logic which works when the patient make abrupt movements
causing the flow looks like to be changed. Whether a fault
happens, the system waits for three subsequent drops and returns
to the normal operation mode.
3 - Implementing Digital Circuits by using FPGA's
The
field-programmable gate array (FPGA) is a relatively new type of
component for the implementation of electronics systems,
particularly for digital systems. It consists of an array of
functional blocks along with an interconnection network, and as
the name implies, its configuration can be determined in the
field, that is , at the point of application. A FPGA circuit provides,
for many applications, an adequate number of transistors in a
single chip package, which includes the functional blocks,
switches for the routing network, and the memory to control both.
In this implementation we are using a re-programmable FPGA from
Xilinx. A very simple structure of such circuit can be seen in
Figure 3.1.
Figure 3.1 - The
architecture of Xilinx FPGA's
It includes a control store in
the form of static RAM (SRAM), which stores the wiring of
functional units, gates, storage elements and interconnect paths.
FPGA families are differentiated by their chip-level architecture
, by the granularity of their functional units and intra- and
interchip wiring organization. The simplest paradigm for FPGA use
is a (silicon) "sand box" in which systems structures
can be built in the time it takes to write to a RAM, and with
complexity levels defined by the chip architecture. Because actual
circuits are defined by the contents of a volatile SRAM control store,
FPGAs address applications in new ways:
The description of a digital
system can be done in three distinct domains: structural domain,
behavioral domain, and physical domain. For each domain there are
different levels of abstraction going from transistor level until
system level. And the same level can be found in each domain, for
example, at the logic level a structural description could be a
logic diagram , a behavioral description could be a set of logic
equations, and a physical description could be a standard cell
layout for an ASIC. The hardware developed in this work was
described in the structural and behavioral domains at the logical
and RT abstraction levels. Using the option for describing the
system (or part of it) in the behavioral domain, technology-independent design
tools allows to describe the circuit in a high level of
abstraction by using a hardware description language (HDL). This description
can be converted automatically by synthesis tools into an
intermediate format that can be targeted to different implementation
styles and different suppliers [Oldfield-95]. The hardware
description language used to describe the IVICS's hardware has been
VHDL [Perry-93] and the synthesis has been done by the Alliance
synthesis tool [CAO-95]. In the following, a short description of
the Alliance Design Tools is given, a more detailed description
can be found in [CAO-95].
The Alliance package is a
complete set of CAD tools for teaching and design purposes, which
allows the description, simulation and synthesis of digital
circuits specified in VHDL at logical and RT abstraction levels.
The package includes the tools described below.
ASIMUT is a VHDL logic simulator. The supported VHDL subset allows both structural and behavioral data-flow description.
GENPAT is a language interpreter dedicated to efficient simulation pattern descriptions.
LOGIC is a logic synthesis tool. The input file is a behavioral description of the circuit using the same VHDL subset as the logic simulator. The output is netlist of gates.
SYF is finite state machine synthesizer.
ALLIGATOR is a optimizer tool that allows mapping from a behavioral VHDL description of a circuit into commercial programmable architectures such as Xilinx.
SCLIB is a MOS standard-cell library that contains about 60 different cells.
GENLIB is a procedural language for netlist capture and placement description.
SCR is a board and route tool for standard-cells.
RING is a specific router dedicated to the final routing of chip core and input/output pads.
S2R stands for "symbolic to real", and translates the hierarchical symbolic layout description into physical layout required by a given silicon supplier.
VERSATIL is a fast design rule checker.
LYNX is a layout extractor. The input is a symbolic layout and the output is an extracted netlist with parasitic capacitance.
LVX is a logical versus extracted net-compare tool.
DESB is a functional abstractor/disassembler for CMOS circuits.
PROOF performs a formal comparison between two behavioral VHDL descriptions.
ALC is a hierarchical symbolic layout editor.
MBK2PS creates a
postscript file from a symbolic layout cell.
During the design
of the IVICS's hardware we have used only the tools Asimut and
Alligator since the target technology in this project was the
family 3020 from Xilinx FPGA. The design flow when developing the
IVICS hardware is shown in Figure 3.2.
Figure 3.2 - The
design flow of the IVICS's hardware
Once a the circuit was described
in VHDL, Asimut was used for simulation by using a pattern description
file (pat format). During the simulation, patterns are
processed and a result file also in the pat format is
generated. Once the simulation is correct, the synthesis can be
started. The Alligator synthesis tools receives a VHDL
behavioral description (data flow) and generates two main output files.
The first one is a optimized behavioral description of the
circuit. The second file is the net-list in the format of some
FPGA vendor. At the moment, only XNF format (Xilinx
Net-list Format) for 3000 family is supported.
4 - A FPGA Based
Implementation of the IVICS System
As mentioned
previously, the IVICS controller system was implemented in
software and in hardware. An overview of the IVICS implementation
can be seen in Figure 4.1.
Figure 4.1 - An overview of the
IVICS implementation
The drop sensor captures the
occurrence of drop. In the case a drop is falling (a signal is
activated - 0 to 1) the time is captured in order to calculate
the current flow. When the signal goes from 1 to 0, it means the
drop is leaving out and the volume is calculated. If the error
flow is greater than 1 drop/min. and smaller than a tolerance
value, the "bang-bang" algorithm is executed in order
to correct this error. For error values greater than tolerance
value, it must be verified if the limit of region is reached in
order to call the range-control algorithm or post-control
algorithm. The range-control algorithm corrects whether the
measured value and the desired value are in distinct regions.
When a drop is not captured, that is the sensor signal does not change and remains in 0, the time is captured and a new drop is waited. If a time-out value is reached, either the range-control algorithm or the pre-control algorithm is called for correct this error. Although it is not shown in the picture, if the range-control is called more than hundred times it means that something wrong is happening, probably the infusion liquid is finished.
All the control algorithms generate a 8-bit instruction, which is used by the block Generate Pulse Sequence, which has been implemented in hardware by using FPGA´s.
In the following, an overview of
the software implementation is given. More details of the
hardware implementation can be found in the section 4.2.
4.1 - The Software of
the IVICS System
The software of the IVICS has
been implemented by using the C++ language, which was chosen due its versatility
and the easy access to the I/O ports of the microcomputer. The
IVICS program is composed of three main procedures: user interface,
hardware/software interface and the control flow routines. These
parts were implemented by using object orientation concepts of
classes in the C++ language. Three classes were created: the
class called graphics is responsible for the user interface, the
class called motor is responsible for the hardware/software
interface and the class denominated algorithms is responsible for
the control flow routines.
4.1.1 - User Interface
The role of the user interface is
to give the user an easy way of communication with the system.
The user interface is responsible for the input of information by
the user and for displaying information by the program. The
information treated by the user interface can be divided into
four categories: input data, output data, error messages and
auxiliary tasks, which are detailed in the following.
* Input Data- The data
entered by the user are the desired flow, the desired infused
volume and the time interval of infusion. These data can be used
alone or together, if the user wants to keep the flow constant,
he/she just needs to inform the desired flow. If the user wants
to infuse a certain volume at a fixed flow, he/she must inform
the desired volume and the desired flow. When the user wants to
infuse a certain volume during an interval of time, he/she must
inform the desired volume and the time interval of infusion.
* Output Data- The data
displayed by the computer are the measured flow, the infused
volume and the time of infusion already gone;
4.1.2 - Hardware/Software
interface
The hardware/software interface is responsible for the reading and sending of signals between the microcomputer and the hardware. The functions performed by the HW/SW interface are implemented in the class called motor and are given by:
4.1.3 - Control flow Routines
The control flow routines are responsible for the processing of the data coming from the hardware. These routines calculate the number of steps and the direction of turn for the stepper motor, generate the error messages and specify the right moment for sending the control signals to the hardware.
4.2 - The
Hardware of the IVICS System
The hardware of the IVICS has
been implemented by using the Xilinx 3020pc68-7 FPGA, which contains
64 CLB's (configurable logic blocks). Each CLB has two function
generators, a combinatorial logic section, and an internal
control section. The CLB also includes five logic inputs, a common
clock input, an asynchronous direct reset input, a clock enable, and
two outputs. A data-in input is also provided for direct input to
the flip-flops within the CLB. This FPGA circuit is a reconfigurable
one and uses static RAM's to store the hardware interconnections,
and functions performed by the function generators. As mentioned
previously, two main tools were used to implement the hardware in
the 3020pc68-7 FPGA: the ALLIGATOR tool and the XDM(Xilinx Design
Manager). Using the hardware description language VHDL, the ALLIGATOR
generates a .XNF(Xilinx Netlist Format) file, that is a structural
description of the circuit and is the input file for the XDM
software. The XDM software has been used to map the XNF file to
the FPGA and to make changes in the circuit manually after it has been
mapped in the FPGA. It was necessary due to the fact that the
circuit description generated by the ALLIANCE doesn't allow to
use some of the FPGA characteristics such as the direct reset
input.
Basically the IVICS hardware is composed of three parts: the communication block, the execution unit and the motor controller, as it can be seen in Figure 4.2.
Figure 4.2 - The
IVICS hardware implementation
4.2.1 - Communication Block
The communication block is
responsible for the exchange of signals between the microcomputer
and the circuit itself. As it can be seen in Figure 4.3, there
are two kinds of signals: data and control.
Figure 4.3 - The
communication block
The input data signal is a eight
bit instruction to be executed by the hardware. This instruction
is composed of one bit indicating the direction and seven bits
giving the number of steps for the stepper motor. The instruction
received is stored in the instruction register when the control
signal EN has been activated by the microcomputer. The output
data signals are the DROP_OUT and the BUTTOM_OUT signals. The
DROP_OUT signal is stored at the DROP_FF register, this one bit register
is set to one when the drop is detected by the drop sensor and is
cleared by the control signal CLR_DROP. The implementation of
this register must also be done manually by using the XDM tool, since
the ALLIANCE does not allow to use the internal reset input of
the FPGA. The signal BUTTOM_OUT is setup when the user press the
button in the hardware, indicating to the software running in the
computer that the unit is activated. By this way, the computer
starts the reading of signals coming from the hardware and sends
data and control signals to the circuit. The control signals are
used to synchronize software and hardware and are described
below:
A VHDL description of this block
can be found in the Appendix A.
4.2.2 - Execution Unit
The execution unit executes the
instruction sent by the microcomputer and informs when the instruction
is completely executed, thus enabling the storing of another one
in the internal instruction register. As it can be seen in the
figure 4.4, this unit is composed of the internal counter, the RD_CONT
register and the EN_I register.
Figure 4.4 - The execution unit
The Internal Enable (EN_I) is a
one bit register that is high when receives the external signal
EN. This strategy of two enable signals, one external and one
internal enable, is used to permit the hardware itself to load
the internal count, releasing, thus, the microcomputer of this
task. The data stored in the internal register is loaded,
asynchronously, in the internal counter each time the clock
signal goes low and the EN_I signal is high. So whether the
microcomputer wants the execution of one instruction by the hardware,
it sends the EN signal. This action sets the EN_I signal to high
and when the clock signal goes low, the data is loaded in the
internal counter. After that, the signal A_RD_CONT is generated
in the RD_CONT register, which causes the microcomputer to send
the signal RST_CONT in order to reset the EN_I register and the
RD_CONT register. By this way, the data in the internal register
is loaded once during the execution of one instruction. After the
internal counter is loaded, its value is decremented until zero
for each clock (CK) transition from zero to one. When the value
zero is reached, the execution unit sets the signal DONE to high,
indicating that the instruction was executed. The two one-bit registers RD_CONT
and EN_I were implemented manually like the DROP_FF register,
because they also need to use the internal reset signal, not
supported by the ALLIGATOR tool. The VHDL description of this block
can be found in the Appendix A.
The motor controller unit
generates a sequence of four bits, which is necessary to turn the
stepper motor in one of the two directions. As it can be seen in
the figure 4.5, this unity receives the external clock signal
(CK) and, from the internal register, the turn direction while
the internal counter is different of zero. The two sequences are
also shown in the figure 4.5.
Figure 4.5 - The
motor controller
The VHDL description for this
block can also be seen in the Appendix A. The FPGA implementation of the
IVICS hardware can be seen in the figure 4.6. This implementation
was carried out by using the family 3020 of Xilinx and has occupied
37 CLB´s.
Figure 4.6 - The FPGA Implementation of IVICS hardware
4.3- Results
A first prototype of the IVICS system has been implemented by using a 486-IBM PC and all results were obtained for the system in closed-loop environment. The main goal of the proposed system is to keep constant the infusion flow for one patient, which could be a value in the typical range from 4 to 80 drops/min, allowing a maximum transitory error of 1 drop/minute. This goal was reached as it can be observed in the figure 4.7, which shows the system behavior for a 40 drops/minute flow rate in steady state. The measured transitory error of the system is 1 drop/minute.
Fig. 4.7 - 40
drops/min. flow in steady state
The figure 4.8 shows the IVICS behavior for a flow rate of 80 drops/minute. Due to the poor precision of the used stepper motor (it has a smaller number of step angles than the system needs), is possible to observe for high rates that the system try to correct the error but the step angle is higher than the necessary leading to an alternation of the error between positive and negative values. This problem can be correct by using a more precise stepper motor.
Figure 4.8 - The
IVICS accuracy for a 80 drop/min. flow
Another important feature to be
measured is the setup time. The system maximum top-down setup time is
23.64 seconds and the maximum bottom-up setup time is 15.89
seconds. The figures 4.9 and 4.10 show some values for top-down
and bottom-up setup times, respectively.
Concerning the system precision and setup time, the results obtained with the IVICS system are better than the results with others controller implementations. For example, the IVISC setup times are 15.89 sec.(bottom-to-up) and 23.64 sec.(top-down) while the CIIM system [Ferraz-93] setup time are 54 sec. (bottom-up) and 30 sec. (top-down). The transitory error to IVISC is 1 drop/min and the CIIM system transitory error is 2 drops/min [Ferraz-93].
5- Conclusions and
future works
This work has presented a FPGA
based implementation for a intravenous infusion controller
system. The whole system was implemented in software and
hardware, where the hardware part was implemented by using
FPGA´s. In comparison with another system implemented completely
in software, the proposed system has shown better performance and
accuracy. An advantage of a mixed implementation of hardware and
software is a better scalability of the system for more than one patient. Additionally
the use of FPGA´s has allowed a rapid prototyping of the system.
In order to improve the
performance of the system, we have started the implementation of
some software functions in hardware. Additionally, we are using
this system as a case study in the development of a
hardware/software codesign methodology [Codes-94]. [Eurodac-94]
and an occam description was generated and is being used as input
description for the partitioning tool developed in the context of
the PISH project, ongoing in our department.
6 - References
| [CAO-95] | CAO-VLSI - Alliance's Reference Manual -Public Domain Software - 1995 |
| [Codes-94] | Barros, E. and Sampaio, A., Towards Provably Correct Hardware/Software Partitioning Using Occam, Proceedings of the third International Workshop on Hardware/Software Codesign Codes/CASHE94, 1994 |
| [Eurodac-94] | Barros, E., Xiong, X. and Rosenstiel, W., Hardware/Software Partitioning of UNITY Language, Proceedings of EURODAC 94, 1994 |
| [Ferraz-93] | Ferraz, Claudio H. C., Um Sistema Controlador de Infusao Intravenosa Multi-Paciente para Salas de Recuperacao Hospitalares, UFPE, 1993 (in portuguese). |
| [Oldfield-95] | Oldfield, John V., Dorf, Richard C., "Field-Programmable Gate Arrays- reconfigurable logic for rapid prototyping and implementation of digital systems", John Wiley &Sons, inc., 1995. |
| [Perry- 94] | Perry, D. "VHDL" , Mc Graw Hill, 1994. |
| [Xilinx-94] | Xilinx XACT Manuals - 1994 |
Acknowledgments
We would like to thank Prof.
Mauro R. dos Santos for the fruitful ideas and discussion about
this implementation. Additionally, we thank the Xilinx University
Program for the donation of the Xilinx tool we have used in the
prototype implementation.
Appendix A
A1- The IVICS Entity
Description
| entity ivics_proc is port ( vdd,vss : in bit; -- power supply data : in bit_vector (7 downto 0); rst : in bit; ck : in bit; en : in bit; drop_in : in bit; button_in: in bit; clr_drop: in bit; rst_cont: in bit; button_out : out bit; drop_out : out bit; motor : out bit_vector (3 downto 0); end : out bit; ); end ivics_proc; |
A2 - The communication block
--
Counter loader control -- This signal
must be reseted by rst_cont signal coming from PC -- This signal
must be reset by rst_cont signal coming from PC -- This block stores the drop data drop_ff: block
(drop_in='1' and not drop_in'stable) begin drop_ff<=guarded
vdd; end block; -- This block
contains system Clocks -- System outputs motor <= a_motor; end <= a_end; drop_out <= drop_ff and a_rst; button_out <= button and a_rst; |
A3 - The execution unit
c_less: block (ck='0' and not ck'stable) begin end block; |
A4 - The motor controller
-- The block that commands the signals sent to stepper motor motor: block (ck_motor='0' and not ck_motor'stable) begin a_motor <=
guarded "1100" when (a_motor="0110"
and dir='0') else "1001" when
(a_motor="1100" and dir='0') else end block; --Bloco de Direction dir: block (en_i='1' and not en_i'stable) begin dir <= guarded reg(7); end block; |
