A safe accurate IV infusion control system.pdf

7/27/2019 A safe accurate IV infusion control system.pdf

1/10

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

Medical facilities use conventionalintravenous (IV) infusion systems in caseswhere the patient needs some kind of pro-grammed medicine or nutrition. Gravity con-trols the simplest and cheapest system, shownin Figure 1a. In this kind of system, however,the ow rate varies with the bottles uid vol-ume and the hoses pressure. Adjusting thedrip feed keeps the rate constant.

This article details our development of acontrol system for conventional gravity-con-trolled infusion systems that guarantees a safeand accurate infusion process. Figure 1bshows such a system. The control system mea-sures the current ow rate through an opticalsensor in the drop window and controls it bycompressing or decompressing the hose witha motor.

We wanted the system to control conven-tional IV infusion systems with hardware andsoftware. This kind of implementation cre-ates a low-cost control system that resists soft-ware faults. Providing this kind of safetybecomes crucial if the microcomputer is alsoused for other purposes. To analyze the vari-ous implementation possibilities, we used thePISH (integrated design of software and hard-ware, or projeto integrado de software e hardware in Portuguese) codesign methodologydeveloped by our research group.

Conventional design problemsIf we can observe the number of drops

falling through the drop window during agiven time period, then we can measure theow rate. In most cases, medical techniciansadjust IVs manually, which can result in impre-cise flow rate values. Manual adjustmentsrequire someone constantly on site to keep theinfusion ow rate constant and to prevent sit-uations of over- and underinfusion. 1

When the patient must receive medicine ornutrit ion through infusion or parenteral feed,this kind of monitoring can become critical,since absorption depends on the infusion ratesaccuracy. Addit ionally, manually monitoringlarge numbers of patients can lead to a stress-ful work environment for medical personnel.All of these factors emphasize the need for anautomatic monitoring system that constantlydistributes the infusion ow rate and signalsstaff members when something goes wrong.

For cases that require programmed medicineor nutrition volume, infusion pumps provideconstant ow rates. Such equipment, however,is very expensive and can become uncomfort-able for patients with involuntary movements.Additionally, the high cost makes home therapymore difcult. Because an increasing number of people have a PC at home, the hardware/soft-ware system is cheaper than infusion pumps.

Edna BarrosMarcus V.D. dos

SantosFederal University ofPernambuco, Brazil

THIS FAULT -TOLERAN T SYSTEM IM PLEM ENTED IN HARDWARE AN D

SOFTWA RE AN D PARTITIONED W ITH A CODESIGN M ETHODOLOGY

REVOLUTION IZES TRADITIONA L IV INFUSION CONTROL SYSTEM S .

0272-1732/98/$10.00 1998 IEEE

A SA FE, ACCURATEINTRAVENOUSINFUSIONCONTROLSYSTEM


2/10

IVICSFigure 2 details the IV infusion control sys-

tem. IVICS, a control system for multiplepatients, keeps the ow rate (in drops/min.)constant. The system also controls the pro-

grammed volume to be infused. Additionally,the system must detect failures in the sensorand the motor, and it must tolerate softwarefaults such as when the microcomputer isturned off.

The system keeps flow values constant inthe range of 1 to 80 drops/min., with a max-imum dynamic error of 1 drop/min. Thesystem receives as input the proper dosingrate. Depending on the equipment andwhether personnel must monitor the volume,the system receives information about thekind of drip-feed unit and the volume to be

infused. After that, monitoring begins. As seenin Figure 2, the system is a closed-loop controlsystem that measures the time intervalbetween successive drops falling through thedrip-feed unit. It activates a step motor thatcompresses or decompresses the drip-feedhose as needed to correct the ow.

We implemented the system partly in soft-ware and partly in hardware. The softwareruns on a PC. For better resource utilization,medical personnel can also use the PC forother purposes.

We specied the system as a set of process-es, as seen in Figure 3 (next page). The userinterface process takes system inputs such asthe desired ow rate, the volume to be infused,and so on. It then notes the systems status,including the measured ow rate, the infusedvolume, and any message errors detecting fail-ure situations.

The user gives the volume to be infused ina unit of volume (usually ml) that i s then con-verted into a number of drops. The resultingnumber of drops depends on the kind of equipment used and the liquid to be infused.For this article, we consider the two most com-monly used pieces of equipment. We only tookone kind of infusion into account, but otherinfusion solutions can be considered as well.

The optical sensor generates a digital signalindicating a drops presence. This signal indi-cates the current ow rate. The ow calcula-tion process periodically reads the drop sensorsstate, measures the time between successivedrops, and returns the current ow rate and

volume in drops/min. We calculated the owrate as ow rate (drops/min.) = 60/timebetween drops(min.).

The flow calculation process also detectssystem failures including sensor fault, drop-per mechanism fault, and motor actuationsystem failure.

To correct errors between the measured anddesired ow rate, the step motor causing itsrotation must receive a sequence of pulses.Depending on the direction of the motor rota-tion, the motor will compress or decompressthe drip-feed hose, thus altering the ow ratevalue. The number of pulses depends on erroras well as ow values (measured and desired).To deal with this feature, we divided the ow

SEPTEM BER OCTOBER 1998

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Motor

Actuation

Opticalsensor

Controller

(a) (b)

Bottle

Dropper

Flow regulator

Hose

Figure 1. C onventional intravenous (IV ) i nfusion system controlled by gravi-ty (a); similar system with automatic ow control (b).

Hardware

Infraredsensor

Motor

Actuation

Hardware

Infraredsensor

Motor

Actuation

Figure 2. I V infusion control system diagram.


3/10

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

rate values considered in the system (1 to 80drops/min.) into a set of 11 ranges, as depict-ed in Table 1. The range calculation processtransforms the flow rate value (measured ordesired) into a range value.

The main process in Figure 3 receives themeasured and desired ow values (with theirrespective ranges) and calculates the ow error.Depending on the error value, the main processexecutes one of four distinct correction algo-rithms. Figure 4 depicts the relation betweenthe ow error and the correction algorithm.

The Bang-Bang (BB) algorithm finelyadjusts the system and corrects small error val-ues in the range of (1 < error < 2) or ( 2 < error< 1). For error values in the range of (2 160

1 80 < rate 160

2 72 < rate 80

3 64 < rate 72

4 56 < rate 64

5 48 < rate 56

6 40 < rate 48

7 32 < rate 40

8 24 < rate 32

9 16 < rate 24

10 8 < rate 1611 8

Number of pulses

Error (drops/min.)

BB

BB

Postcontrol

PrecontrolRange control

Range control

1 2 3 4 5 6 7 88 7 6 5 4 3 2 1

Figure 4. Error values and correction algorithms.


4/10

the main process sends a message to the user.The actuation process generates the prop-

er pulse sequence that eventually rotates themotor a number of steps in a certain direc-tion. The sequence generation depends on themotor used. For this article, we used a motorwith a 3.6%-graded step angle.

PISH methodologyAs mentioned, we implemented some con-

trol system processes in software and others inhardware. We partitioned the hardware andsoftware according to PISH codesignmethodology.

Hardware/software codesign is a new designparadigm for the joint specication, design,and synthesis of mixed hardware and softwaresystems. Designers implement such systemswith general programmable components (suchas microprocessors and microcontrollers) aswell as with application-specic ones. The for-mer, called software components, consist of common-off-the-shelf (COTS) components.The latter, called hardware components, canbe implemented by using FPGAs or ASICs.Systems that combine software and hardwarecomponents have a variety of implementationtechnologies and interfaces with a wide rangeof real-time data rates. Our interest in codesignwas driven by the increasing complexity of dig-ital systems, the need for early prototypes tovalidate specications, and the goal to providefeedback during the design process. 2,3

Our IVICS system was implemented

according to the PISH methodology forhardware/software codesign. This methodol-ogy uses occam2 as a specication mechanismand aims to address control-dominated appli-cations. When analyzing a system implemen-tation in hardware and software, the PISHsystem attempts to address key points not cov-ered by other codesign approaches:

it considers hardware/software trade-offsand distinct hardware architectures 4 tocomplete partitioning,

it assures the correctness of the parti-tioning process through formal verica-tion techniques, 5 and

it obtains a virtual prototype in an earlyphase of the design process.

The PISH codesign system comprises alldesign process phases, as depicted in Figure 5.PISH partitions the occam2 specication intotwo sets of processes: one in software and theother in hardware. This occurs in such a waythat we can formally verify that the parti-tioned descriptions have the same semantics asthe original one. PISH also generates com-munication processes during the partitioningphase. After partitioning, the processes wehave to implement in hardware are synthe-sized, and the software processes are compiled.

We generated a rst prototype that imple-mented the software processes in a micro-processor (currently we use a transputer) andthe hardware processes with reconfigurable


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

Estimation

Implementation

Compilation

Verification

Partitioning

Synthesis

Prototyping

Hardware

Software

SW

HW

HW

Program convolution

SEQ i=0 FOR 2PAR

IF (x[i] >= 0 c:= x[i],x[i] < 0 c:= x[i]/2)

IF (x[i+1] >= 0 d:= x[i+1],x[i+1] < 0 d:= x[i+1]/2)PAR j=0 FOR 4

e[j]:= x[f(i, j,)]PAR

w:= k*e[i]PAR j=0 FOR 4

y[j]:= y[j] + e[j]*(c+d)

Figure 5. The P IS H design ow.


5/10

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

logic such as FPGAs. We also generated aninterface between the hardware and software.In the PISH codesign system, we used a pro-totyping environment based on transputerand recongurable logic (FPGAs).

Once we validated the system, we imple-mented the hardware components (the wholesystem) as an ASIC. We developed techniquesfor layout synthesis that allow layout genera-tion for sea-of-gates technology, which is atechnology for implementing ICs.

One key point in a codesign system is thepartitioning method. The PISH system madean enormous contribution to hardware/soft-ware codesign research (including heuristicalgorithms to the partitioning problem). 2-4,6,7Recently, two works 8,9 suggested the use of for-mal partitioning process methods. Althoughthese approaches use formal methods forhardware/software partitioning, neither of them formally verifies that the partitioningpreserves the original descriptions semantics.

As mentioned previously, the PISH co-design system uses occam2 10 as a descriptionlanguage. In the partitioning strategy weadopted, a series of algebraic transformationsapplied into the program partitions an occam2program. We used occam2 because it is basedon communicating sequential processes 11 andthus has a simple and elegant semantic in termsof algebraic laws.

Partitioning approachoverview

To preserve the originaldescriptionssemantics, the par-titioning process applies a set of

transformation rules in anoccam program, guided by theresults of a cost analysis basedon clustering techniques. Thetarget architecture underlyingthe hardware/software-parti-tioning algorithm is predenedwith only one software com-ponent. The hardware compo-nents architecture, however,can include many functionalunits working in parallel andcan therefore exhibit distinct

degrees of parallelism.Initially, we transformed theoriginal description into anoth-er description given by a set of

concurrent simple processes. (A simple processdoes not include nested constructors, with theexception of replicators. 12) A set of rewriting rulesassures that the semantics are preserved. 12 Due tothe concurrent nature of the processes, com-munication must be introduced among sequen-tial data-dependent processes.

If we split the original description into a setof simple processes, we allow a better designspace exploration to nd the best partitioning.After the split phase, a cost analysis nds thebest hardware/software process partition, whichfullls the design constraints. First we attach aset of hardware implementation possibilitiesconcerning distinct degrees of parallelism toeach process. This occurs during the classica-tion phase. After that, we choose one processto be implemented in software. By taking oneimplementation alternative into account foreach process, we group the processes into clus-ters in the clustering phase. The main criteriawe consider during this phase are similaritybetween processes, communication costs, area,delay, and software fault tolerance.

The result of the clustering process is anoccam2 description representing the obtainedclusters sequence with additional informationindicating whether we should serializeprocesses kept in a cluster. The serializationcan eliminate unnecessary communicationintroduced during the splitting phase. We

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IVICS

IEEE MICRO

P4

...Sequential

...1 multiplier

...Parallel

n multipliers...

Parallel

n multipliers

SoftwareHardware

Cut line

Resourcesharing

...Parallel

n 2 multipliers

P 1, P 6.1 , , P 6.4P 2 P 3 P 4 P 5.1 P 5.2 P 5.3

CHAN ch 1, ch 2 : PARPAR{SEQ}( P 1, P 6.1 , P 6.4 )PAR{PAR, SEQ}( P 5.1 , P 5.2 , P 5.3 )

(a)

(b)

(c)

PAR i = 1 for N PAR j = 1 for N

a [i , j ]: = f (b [i , j ])

Figure 6. T he classi cation and clustering phases. Classi cation (a), clustering (b) , and clus-tering result (c).


6/10


7/10

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

processes P 0and P 11 must be implemented inhardware. Furthermore, suppose system feed-back erupts between processes P 0 and P 11. Bytaking into account the data dependencybetween process and system feedback, fourpossible paths make up a closed loop in thedesign flow (dashed arrows in Figure 7). Byconsidering the fact that processes pertainingto such paths are not good software candidates,the algorithm determines that only processesP 2 and P 3 could be implemented in software inthe initial allocation phase.

Once we choose a process to be imple-mented in software, the hardware/softwarepartitioning of the remaining processes takesplace. We want to group the process sets inhardware or software clusters according tosome criteria. The process-set partitioning isperformed with a multistage hierarchical clus-tering algorithm. 13 First, a cluster tree is built(see Figure 6b). Considering criteria like sim-ilari ty among processes, communication cost,and resource sharing allows us to build thetree. To measure the similarity among process-es, we dene a metric that allows us to quan-tify the similarity of two processes byanalyzing their functionality, the currentimplementations degree of parallelism, thepossibility of implementing the processes inpipeline, and assignment mult iplicity.

When software fault tolerance is required,the following heuristic assures that at least oneset of processes that make up a closed-looppath should be kept in a hardware cluster.When building the cluster tree, processes per-

taining to the greater number of paths thatmake up a closed loop should be kept in thesame cluster. In Figure 7, for example, process-es P 0, P 4, P 5, P 10, and P 11 should be kept inthe same cluster, since they pertain to all fourpossible closed-loop paths.

Cutting the cluster tree at some level gen-erates the cluster set (see Figure 6b). We chosethe level according to the communication costminimization and to the fulllment of con-straints such as area and delay.

To allow formal partitioned occam2 descrip-tion generation in the joining phase, the clus-tering output is an occam2 description. Thisdescription reects the clustering trees struc-ture with annotations indicating whetherresources should be shared and to what extentthe underlying processes should be serialized.

Control system implementationTo apply the PISH codesign methodology

and implement the infusion control system inhardware and software, we describe the sys-tem behavior in occam2 as a set of concurrentprocesses. We implemented each system mod-ule depicted in Figure 3 as an occam2 process.

Excepting the user interface process, wedescribed all other processes by using theoccam2 parallel replicator with a factor of 10.This means that each process should be con-sidered as a set of 10 processes running in par-allel (one for each patient). We xed softwareand hardware process implementations dur-ing the system specication. We annotated theuser interface process as a software process

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IVICS

IEEE MICRO

Volume

Flow rate

Status

User

interface

Volumecalculation

Range

calculation

Flowcalculation

Main

process

Correction

algorithms

Actuation

process

Opticalsensor Motor

HardwareSoftware

Control data flowStatus message flow

Figure 8. H ardware partitioning results.


8/10

we considered the motor actuation process tobe a hardware process. In the rst case, a soft-ware implementation makes sense, since thisprocess represents the interface between theuser and the system. A software implementa-tion allows the development of a friendlierinterface. In the second case, the motor actu-ation process is the interface between the con-trol system and the motor. A hardwareimplementation of this process allows an eas-ier interface implementation.

During the hardware/software-partitioningphase, we generated two different part itions.We generated the rst partition by consider-ing performance, exibility, and hardware areaminimization as main criteria. We generatedthe second partition by considering the con-trol systems software fault tolerance. Weobtained both partitioning results by takinginto account a predened target architectureincluding only one software component(microprocessor).

The partitioning result for the rst systemversion appears in Figure 8. The main criteriaconsidered in this case were better perfor-mance, more exibility, and a small hardwarearea. As depicted in Figure 8, we only imple-mented two processes in hardware (all the oth-ers were in software).

The flow calculation process has beenimplemented in hardware together with theactuation process, one for each patient. Byperforming these tasks in parallel, the systemcontrols more patients without accuracy or

precision degradation.In the second version, we considered software

fault tolerance. All processes that pertained toat least one path making up a closed loop werekept in a hardware cluster. The closed-loop pathimplemented in hardware was the path mini-mizing the hardware area (for example, hard-ware costs). As mentioned, this featureguarantees software fault tolerance, since theow is controlled when the software compo-nent stops. Ensuring this kind of fault toleranceis very important in critical applications like thisone, since in most implementations the soft-ware runs on a PC that is also used for otherpurposes. In the case of any PC fault or reboot,all infusion processes remain controlled with-out needing a new start process when the soft-ware restarts.

Once we perform the system partitioning,the next phase is system prototype generation.Since we implemented this application to vali-date the partitioning methodology described inthe previous section, a transputer served as thesoftware component. In a more realistic systemimplementation, the software could be imple-mented in a PCs CPU without any problem.

A prototype of the second version can beseen in Figure 9. The prototyping platformincludes the transputer T800 (software com-ponent) and the XC4000E FPGA. We insert-ed the transputer board into an IBM PC slotand then we implemented software/hardwarecommunication with the IBM PC bus. Twoadditional processes implemented the hard-


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

(a)Transputer

(b)FPGA

Userinterface

Algorithm 1

Algorithm 2

Algorithm 3

Hardwareinterface

Algorithm

4

Mainprocess

Softwareinterface

MotorPC bus

PC Flowcalculation

Actuationprocess

Opticalsensor

Rangecalculation

Volumecalculation

Figure 9. System prototype in software (a) and hardware (b) .


9/10

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

ware/software interface: one on the softwareside and the other on the hardware side.

In the PISH codesign methodology, the com-munication model is predened, where the soft-ware process (master-slave model) controls all

software/hardware communication, but hard-ware and software processes execute in parallel.We defined a handshake protocol to syn-

chronize communication, which is performedby reading and writing I/O addresses. Becausewe used the IBM PC bus as a communicationmedium, each signal transition of the proto-col must be codied as a message representedby an 8-bit code. The software sends messagesto the hardware, and the hardware replies tothem by providing the requested information.

On the hardware side, we designed mod-ules for address decoding and message inter-pretation. The software writes into the inputdata and message registers, and reads from sta-tus and output data registers, all of them onthe hardware side. For example, when the soft-ware wants the current ow rate of infusion

system number 0, it sends an 8-bit messagecodified as 00011011 to the I/O address300H (patient 0). The hardware replies to thisrequest by setting the ready data bit in the sta-tus register (bit 0) and by providing, after that,

the ow rate in the output data register. Thesoftware waits for the hardware reply by read-ing the hardware status register (for example,the I/ O address 310H) until the bit 0 is set to1. After that, the software reads the I/Oaddress 300H, which corresponds to the hard-ware output data register.

As mentioned, we implemented the hard-ware processes with FPGAs. The hardwarearea in number of configurable logic blocks(CLBs) and the number of pins used appearsin the right side of Figure 10. The number of code lines of the processes implemented in

software is also shown. Part of the FPGA lay-out appears in the left side of the gure.We measured the prototype systems stabil-

ity for two distinct rate values, as depicted inFigure 11. As shown in the gure, the maxi-mum error in the 40-drop/min. ow rate was 1 drop/min. For a rate value equal to 80drops/min., the average ow error is also 1drop/min., but some system oscillation existsbetween greater error values. The step motorcauses this oscillation. If we use a more accu-rate step motor (one with a smaller step angle),thi s oscillation would not occur.

Weve presented an IV infusion controlsystem, implemented in software andhardware, assembled with a hardware/softwarecodesign methodology. We implemented two

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IVICS

IEEE MICRO

Used

Number of CLBs

Number of pins

FPGA XC4000EHardware

584

39

Program in occam

1,522 program lines

FPGA layout

Software

Figure 10. H ardware and softw are implementation.

0

20

40

60

80

100

F l o w r a t e

( d r o p s

/ m i n

. )

F l o w r a t e

( d r o p s

/ m i n

. )

1 35 69 103 137 171 205 239

Time (s)

0

20

40

60

80

100

1 36 71 106 141 176 211 246

Time (s)(a) (b)

Figure 11. System stability for 40 (a) and 80 (b) drops/min. ow rates.


10/10

versions by considering criteria such as per-formance, hardware area, and software faulttolerance (second version). The latter versionpresented a better response time, more exi-bility, software fault tolerance, and protection

from software component failures. This fea-ture is very important, especially in cases wherethe microprocessor is used for other purposes.

We calibrated the IVICS system by con-sidering a specic model of drip-feed equip-ment. In future work, we propose theinclusion of a calibration function in the sys-tem. This feature should permit the system toadapt itself to other drip-feed equipment,when running in calibration mode. Anotherimprovement could be the use of more pre-cise algorithms to correct the ow error. M I CR O

AcknowledgmentsThis work was supported by the Brazilianresearch council, CNPq, ProTeM-CC researchproject number 680074/94-5, and by theEuropean Community research KIT programnumber 128.

References1. A. Shoukas and C. Rothe, The Venous Sys-

tem, The Biom edical Engineering Handbook ,

CR C/IEEE Press, P iscataway, N. J., 1995.

2. R. G upta and G. D e M icheli, System-level

Synthesis Using Reprogrammable Com -

ponents, Proc. European Design Automation Conf. , IEE E Com puter Society Press, Los

Alamitos, Calif. , 1992, pp. 2-7.

3. D. G ajski and F. Vahid, Specication and

D esign of Em bedded H ardware-Softw are

Systems, IEEE D esign & Test of Com puters ,

Vol. 12, No. 1, 1995, pp. 53-67.

4. E . Barros, H ardware/Software Partitioning

Using UNITY , doctoral thesis, U niversity of

Tuebingen, Institute of Computer Science,

G ermany, 1993.

5. E. Barros and A. Sampaio, Towards Probably

Correct Hardware/Software Partitioning Using

O ccam, Proc. Third Ann. Workshop on HW /SW

Codesign , IEEE CS P ress, 1994, pp. 210-217.

6. R. Ernst, J. Henkel, and T. B enner, Hardware-

Softw are Cosynthesis for M icrocontrollers,

IEEE D& T , V ol. 10, N o. 4, 1993, pp. 64-75.

7. P.V. K nudsen and J. M adsen, PA CE: A

D ynamic Programm ing Algorithm for

Hardware/Software Partitioning, Proc.

Fourth Int l Workshop on HW /SW C odesign ,

IEEE CS P ress, 1996, pp. 85-92.

8. C. Carreras et al., A C odesign M ethodology

Based on Formal Specication and H igh-level

Estimation, Proc. Fourth Intl W orkshop on

HW/SW Codesign , IEEE C S P ress, 1996, pp.

28-35.

9. T. Cheung, G . H ellestrand, and P. K anth-

amanon, A M ultilevel Transformation A pp-

roach to Hardware/Software Codesign: A Case

Study, Proc. Fourth Int l Workshop on HW /SW

Codesign , IEEE CS Press, 1996, pp. 10-17.

10. D. P ountain and D. M ay, A T utorial Intro-

duction to O CC AM Programm ing , Inmos

BSP Professional Books, London, 1987.

11. C .A.R. Hoare, Communicating Sequential

Processes , P rentice Hall, U pper Saddle River,

N.J., 1985.

12. L. Silva, A. Sampaio, and E. Barros, A

N ormal Form R eduction Strategy for Hard-ware/Software Partitioning, Lecture Notes

in Computer Science , Springer Verlag, Heid-

elberg, G ermany, 1997, pp. 624-643.

13. E. Barros and W. R osenstiel, A Clustering

A pproach to Support Hardware/Sof tware

Partitioning, C omputer-A ided Software/

H ardware Engineering , J. R ozenblit and K.

Buchenrieder, eds., IEEE P ress, 1994, ch. 11.

Edna Barros is an associate professor at theFederal University of Pernambuco (UFPE),Brazil. Her interests include HW/SW co-design methodologies, embedded critical sys-tem design, specification mechanisms, andrapid prototyping. Barros received the MS incomputer science from UFPE and the PhDfrom the University of Tuebingen, Germany.

Marcus V.D. dos Santos received the MS inelectronic engineering from UFPE. He stud-ied electronic engineering at the University of Pernambuco. H is research interests includeHW/SW codesign, embedded systems (in themedical eld), and computer architecture.

Direct questions concerning this article toEdna Barros, Depto. de Informatica, UFPE,Caixa Postal 7851, Cidade Universitaria, CEP.50740-940 Recife, PE, Brazil; [email protected].


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

Documents

A safe accurate IV infusion control system.pdf