A ControlSystemfor aRadiationTherapy Machine

JonathanJacky�, RuediRisler, David Reid,

RobertEmery, JonathanUnger�, MichaelPatrick

�

RadiationOncology, Box 356043Universityof WashingtonSeattle,WA 98195-6043

TechnicalReport2001-05-01

May 2001

�emailjon@u.washington.edu, telephone(206)-598-4117,fax (206)-598-6218�Presentaddress:Radionics,BurlingtonMA�Presentaddress:Hydro-Aire,BurbankCA

1

Abstract

This reportdescribesa new computercontrolsystemfor a radiationtherapy machinewithan isocentricgantryanda multileaf collimator. It discussesthe motivation andrationaleforsomeof the featuresanddevelopmentactivities, andreportsseveralmeasuresof developmenteffort, performance,andquality, determinedafteralmosttwo yearsof operatingexperience.

Notable featuresof the control systeminclude constructionbasedon standard(vendor-independent)hardwareandsoftwarecomponentsconnectedbyanetwork,asimpleandefficientuserinterface,closeintegrationwith thetreatmentplanningsystem,automatedrecordkeepingfor patientqualityassuranceandmachinemaintenance,andeaseof maintenanceandupgrading.Separationof control functionsfrom datamanagementfunctionsresultsin a control programwhich is small,fast,andfeasibleto analyzethoroughly. Choiceof featuresandinternaldesignwereinformedby fifteenyearsexperienceusingandmaintainingcomputercontrolledtherapymachines.

Thedevelopmentmethodwaschosento ensureexceptionalsafety, reliability, andclinicalacceptability. Much of thedetailedspecificationwasexpressedin formal (mathematical)nota-tion. This formal specification(not theprosedescription)servedasthebasisfor mostcoding,testplanning,andsafetyanalysis.Testingandreviews weresupplementedby new automatedanalysesmethodsincluding theoremprovingandmodelchecking.

2

1 Intr oduction

Several qualitiesarerequiredof any radiationtherapy machine:accuracy, easeof use,efficiency,anda manifestlysafeandcorrectdesign. Additional qualitiesbecomeimportantwhena uniquemachinemustbesupportedby a small in-houseengineeringstaff: easeandeconomyof upgradesandmaintenance.Herewe reportseveraldesignfeaturesanddevelopmentactivities whichenabledusto achieve thesequalitiesin a therapy machinecontrolsystem.

Wedevelopedanew computercontrolsystem(bothhardwareandsoftware)for theisocentrictreat-mentunit at theClinical NeutronTherapy System(CNTS)at theUniversityof WashingtonMedicalCenterin Seattle[33, 22].

We describethreekinds of innovations: in the featuresvisible to the usersof the machine,in thesysteminternalswhich areonly visible to the engineers,andin the developmentmethodusedtowrite thecontrolprogramandassureits safetyandcorrectness.

Choiceof featuresandinternaldesignfor the new control systemwereinformedby fifteen yearsexperienceusingandmaintaininga one-of-a-kindcomputercontrolledtherapy machine.By com-monly useddefinitions,we have beenroutinelyperformingconformaltreatmentwith a computer-controlledtherapy machinesince1984. We alsohave several yearsof experiencewith computer-controlledlinearacceleratorsfrom commercialmanufacturers.

1.1 Relatedwork

Theliteratureontherapy machinecontrolsystemsis scant.Karzmark[23] providesanearlyreviewof therapy machinetechnologyincluding controls. Early computercontrol systemsuseda mono-lithic designwith asinglemastercontrolcomputerandnonetwork [27, 26, 40]. Distributedcontrolsystemsbasedon networked componentshave beenusedat large researchacceleratorsfor sometime [4] andhave alsobeenappliedto protontherapy [36, 32]. Mageraset al. [30, 29] andFraasset al. [5] constructedconformaltherapy controlsystemsby networking a workstationrunningcus-tom softwareto thecontrolcomputerprovidedby thetherapy machinemanufacturer. Approachesto integratingtreatmentplanningcomputersandtherapy controlsystemsarereviewed by Kalet etal. [22].

3

2 Systemdescription and history

Exceptfor particletype (neutrons)andsize(150cm sourceto axis),our neutrontherapy machineis similar to a moderntherapy linac with a leaf collimator(Fig. 3)1. Clinical trials have shown thatneutronradiationis themosteffective therapy for somecancers[25].

Computercontrol is a vital part of the systemandhasdramaticclinical impactbecauseit is nec-essaryto produceshapedneutronfields with the leaf collimator in order to avoid unacceptablecomplicationsin neutrontherapy [1]. Ourcollimatorhasno jawsor field shapingcomponentsotherthantheleavesthemselves(it doesnot supportexternalshieldingblocks).Theonly way to deliverany field (evenasquare)is to setup thecollimatorleavesundercomputercontrol.

TheMedicalCenterplansto operatethisuniquefacility for anextendedtimeinto thefuture. In July1999our new systemreplacedthe manufacturer’s original control hardware andsoftware whichhadbeenin usesincethemachinewasinstalledin 1984.We anticipatea long lifetime for thenewsystemaswell.

3 Overall requirementsand designphilosophy

In order to designa computercontrol system,it is necessaryto have an overall philosophycon-cerningthepurposeof computercontrolandtheappropriaterolesof thecomputer, traditional(non-programmable)control mechanisms,and the humanoperators. We believe that poor choicesatthis level (or failure to make deliberatechoicesat all) werethe root causeof accidentsinvolvingcomputer-controlledradiationtherapy machines[27, 26]. Thereforewe make our designphiloso-phyexplicit here.

The primary purposeof the computercontrol systemis to enforcethis safetyrequirement:Thetherapybeamcanonly turn onor remainonwhentheactualsetupof themachinematchesa storedprescriptionthattheoperator hasselectedandapproved. Mostof thedesignarisesfrom elaboratingthis singlerequirement:the computerprovidesa databaseof prescribedfields anda way for theoperatorto selectone;thecomputercontinuallyscansall theactualsettingsandcomparesthemtotheprescribedsettings,andsetsinterlocksthatkeepthebeamoff if they donotmatch.A secondarypurposeof thecomputercontrolsystemis to maketreatmentsmoreefficientby automaticallysettingupinternalmotions(leaves,wedges,etc.)andotheritems(thedosimetrysystem)thatdonotpresentcollision hazards.Anothersecondarypurposeof thecomputercontrolsystemis to log informationusedfor recordkeeping,quality assurance,andmachinemaintenance.

1This figureappearsat theendof thereport

4

Controlsoftwareis laboriousto developanddifficult to make correct.Weonly useit wherewe canjustify theeffort andrisk: in data-intensive operationswhereit is unlikely thatanon-programmablemechanismcouldbemadeefficientandreliable.Wecontinueto usehard-wiredmechanismswherethey areeffective, includingmany safetyandequipmentprotectionfunctions.

The therapy machineremainssafeif any computerhaltsor resetsor its programaborts(crashes)at any time. Local (nonprogrammable)mechanismsplacetheequipmentin a safestate(beamoff,motionsdisabled)if the controlling computerfails. Essentialdataaresaved: electromechanicalcountersretainthemostrecentlymeasureddose,evenif all power to thefacility is lost.

We distinguishcontrol functionsfrom datamanagementfunctionsanddelegatethemto differentprogramsandcomputers.Controlfunctionsmustbeexecutedto actuallyirradiatethepatient,whiledatamanagementfunctionsarepreparationsor followupsto treatingthepatient(suchasmaintain-ing theprescriptionfile). Most of thecontrol functionsexecutein a therapy control program thatrunsonaspecial-purposeembeddedcomputer, while datamanagementfunctionsexecutein severalprogramsthatrunongeneral-purposedesktopcomputers2. Datamanagementprogramspreparein-putfiles(suchastheprescriptionfile) andthetherapy controlprogramonly readsthem.Thetherapycontrolprogramonly writescertainoutputfiles (suchastreatmentrecords)anddatamanagementprogramsanalyze,display, andprint them3. This separationbetweencontrolanddatamanagementkeepsthecontrolprogramsmallandenablesusto concentrateeffort on makingit correct,reliable,andefficient.

Operators(andpatients)shouldnever have to wait for the computer. Whenthereis a perceptibledelay, it shouldarisefrom someunavoidableprocessin theenvironmentor thecontrolledequipment(for example,waitingfor thecollimatorleavesto reachtheirprescribedpositions).Time-consumingfile operationsshouldbeavoidedby keepingprogramsanddatain controlcomputermemorywhen-ever possible.

Primaryresponsibilityfor thesafetyandcorrectnessof therapy remainswith thehumanoperators.It is the therapist’s job to identify the patient,selectthe fields prescribedfor that patienton eachtreatmentday, andconfirmthattheprescribedsettingsandotherinformationstoredin thecomputerareconsistentwith otherdocumentation(paperchart,printedtreatmentplanetc.).It is thetherapist’sjob to positionthe patient,to guideexternalmotionsof the therapy equipmentthat might presentcollisionhazards(gantryetc.),andto indicatewhento turnonthetherapy beam.It is thetherapist’sjob to observe the patientandmachineryduring the treatment,to stopthe treatmentif problemsoccur, andto noteunusualoccurencesandreportthemto theengineeringstaff. It is thetherapist’sjob to keepa paperrecordof which treatmentshave occurredandthedosedeliveredfor eachfieldon eachtreatmentday, asacross-checkon thecomputerrecords.

2Thereareadditionalcontrolprogramsandembeddedcomputers(section5.1).3A network makesit possiblefor programsrunningon differentcomputersto usethesamefiles (section5.1).

5

4 Featuresvisible to users

In this subsectionwe describefeaturesvisible to therapistsandotherusers:theoperator’s console,integration with the treatmentplanningsystem,and recordkeeping. We devoted greateffort toachieving usabilityandefficiency. Thesearenot merelymattersof convenience.Poorlydesignedfeaturescan make a systemerror-proneand difficult to check. Details appearin the therapist’sguide[15] andthereferencemanual[14]4.

4.1 Operator’s console

Theoperator’s consoleprovidesa color graphicworkstationwith a keyboard,but thebeam-onandbeam-off functionsareprovided by hard-wiredbuttonson a controlpanel(Fig. 1). TherearealsolampsandnumericLED indicatorson thepanelfor a few conditionsandquantitieswhich requireconspicuousand uninterrupteddisplay. A few indicatorsand functionsthat are provided at theworkstationarealsoprovidedby lampsandbuttonsin thetherapy roomaswell, to save therapists’stepsandtime.

X TERMINAL

PATIENT VIDEO MONITORDIGITAL

ELECTROMETER

TREATMENTCONTROL

BEAM ON

�� �

BEAM OFF

�� �

CONSOLEENABLE KEY

��

��

DOSEMONITORING

(LED’s)

PATIENTINTERCOM

EMER-GENCYSHUTDOWN

OPENTHERAPY

DOOR

�

Figure1: Therapy controlconsole

4Most projectdocumentsareavailablefrom http://www.radonc.washington.edu/physics/cnts/

6

There is just one workstationat the console,with a single video display and keyboard. Somecomputer-controlledtherapy machinesusetwo or more displaysandkeyboards(with a separateworkstationjust for theleaf collimator, for example).We believe this is unnecessarilycomplicatedandwastesspace.

It hasbecomeusualfor computerprogramsto displayseveral (or many) panelsor windows, con-trolled by a pointingdevice or mouse(our own treatmentplanningprogram[21] is oneexample).This is calledthedesktopmetaphor; it wasinventedto helpautomateoffice work. We believe thisstyle is not well-suitedto a therapy machine.Treatinga patientis not like typical office work; thetherapist’s attentionshouldusuallybefocusedon thepatient,not thecomputer.

We adopteda control panelmetaphorinstead.Theworkstationdisplayresemblesa controlpanelwith lampsandotherindicators(Figs4, 5, 6, 7)5. Theoperatorissuescommandsby pressingkeyson a keypad,like pushingbuttonson a controlpanel(not like typing at a keyboard).We do not usethemouse(whichwouldbedifficult to useamongthechartsandfilms thatoftenoccupy theconsoledesksurface). In general,thedisplayshows fewer itemsbut is clearerthantypical office software(oursusesa largertypeface,color coding,andno overlappingwindows).

Several indicatorsarealwaysvisible on the display: the currently selectedpatientandfield, theoperator(therapistor physicist)on duty, and six subsystemlamps. Eachlamp is red when itssubsystemis not readyfor a treatmentandgreenwhenit is ready;yellow indicatestheoperatorhasdeliberatelyoverriddena conditionwhich would normallybeindicatedin red. Whenall lampsaregreenor yellow, theoperatormayturnon thebeamby pushingabuttonon thecontrolpanel.Whenany conditionoccursthatcausesthebeamto turnoff, at leastoneof thelampsturnsred.

Theoperatorpresseskeysto selectthecontentsof thelargecentralpartof thedisplay. Somescreensshow the patientsandfields in the prescriptiondatabase,so the operatorcanselectone(Fig. 4).Anotherscreenshowsasummaryof thecurrentlyselectedfield (Fig. 5). Otherscreensshow detailsof particularsubsystems(Fig. 6), and othersshow calibrationsand other diagnosticinformation(Fig. 7). Thereare20 differentscreens.Of these,11 (includingFig. 7) areintendedfor engineersandtechnicians,not therapists.Therapistscanperformtypical (uneventful) treatmentsusingonlythree:thepatientsscreen,thefieldsscreen(Fig. 4) andthesummaryscreen(Fig. 5).

For a typical treatmentthetherapistselectsa patient,selectsa field, displaysthesummaryscreen,pressesa key to automaticallyset up the dosimetrysystemand internal motionswhich posenocollision danger(leaf positionsetc.),andentersthe treatmentroomto positionthepatientandsetup externalmotions(gantryrotationetc.). As eachsubsystemsetsup, its lampturnsgreen.Whenall lampsaregreen,the therapistpushesthebeam-onbutton. Whenthedosimetrysystemdetectsthat the prescribeddosehasbeendelivered,the beamturns off automaticallyand the dosimetrysubsystemlampturnsred.

5Thesefiguresappearat theendof thereport.Thepatientnamein thefiguresis fictional.

7

Thecontrolprogramdoesnotrequiretherapiststo performoperationsin aparticularfixedsequence.Most operationsare available at all times, althoughsomecommandsare disabledby particularconditions. For examplethe therapistcan always display the list of fields (Fig. 4) but it is notpossibleto selectanew field while thebeamis on.

Certainoperations(changingcalibrationfactorsetc.) areonly available to physicists(includingengineersandtechnicians).Eachoperatormustlog in by typing a usernameandpassword (this istheonly operationwherea therapistmusttypeat thekeyboard),andis identifiedasa therapistorphysicistat this time.

4.2 Integration with the tr eatmentplanning system

Theonly way to entertherapy fields into thecontrolsystemis to transferthemfrom thetreatmentplanningprogram. We have observed this disciplinewithout exceptionsincethe machinebeganoperation[22]. Thereis no way to enteror edit fieldsat the therapy controlconsole.The therapycontrolprogramonly readstheprescriptionfile, it neverwritesit or updatesit. Theprescriptionfileis maintainedby two datamanagementprograms:thetreatmentplanningprogramandthearchiver.

New patientsandfieldsareaddedto theprescriptionfile by the(locally developed)treatmentplan-ning program[21]. A dosimetristat a treatmentplanningworkstationusesthis programto storethecompletedneutrontreatmentplanin afile server andnotifiesthetherapistthattheplanis ready.Thetherapistrunsthetreatmentplanningprogramat a differentworkstationin theneutrontherapycontrol room,retrievestheplan,reviews it, and(if it is satisfactory)selectsandconfirmstheplan-ningprogram’s transferoperation.At thispoint thetherapisttakesresponsibilityfor performingthepropertreatment.Theplanningprogramwritesout thepertinentpatientandfield setupinformationandappendsit to thecontrolsystemprescriptionfile.

It is usualto transferadditionalfieldsfor thethesamepatientondifferentdays,afterphysiciansanddosimetristsrevise theplanor addboostfields. New fieldsaresimply appendedto theendof thefile. To changeafield (evenoneleaf), it is necessaryto transferacompletenew version;theearlierversionremainsin thefile but thetherapistmarksit superceded.

All fieldsfor a patientremainin theprescriptionfile until thepatientcompletesthecourseof treat-ment. Thenthe therapistrunsthearchiver programto remove thepatientandall of thefields to apermanentarchive.

To readthe latestversionof theprescriptionfile into the therapy controlprogram,the therapistattheconsolepressesthekey to displaythe list of patients(this is theusualpreliminaryto selectinga patient,whetheror not theprescriptionfile haschanged).Theprogramreadstheentirefile intomemory, replacingall of the previous contents. If the programis unableto readthe file, or if it

8

encountersanerroror anindicationthatthefile hasbecomecorrupted,it retainsall of thepreviousdatasomemorycontentsremainconsistent.Treatmentscancontinue(but perhapswithout themostrecentpatientsandfields)even whenthereis a problemwith the treatmentplanningfile server ortheprescriptionfile.

4.3 Recordkeepingfor patient quality assuranceand maintenance

Thecontrolprogramandthedatamanagementprogramsmaintaina completepermanentrecordofsuccessive stepsin thetreatmentprocessfor every patient.

Theprescriptionfile recordsall prescribedfieldsfor eachpatientcurrentlyundertreatment,includ-ing the dateeachfield wastransferredfrom the treatmentplanningsystemandthe therapistwhoperformedtransfer(Fig. 4).

Thetherapy controlprogramkeepsarecordin memoryof eachfield’s totaldoseto date,dosefor thecurrentday, andnumberof treatmentdaysto date. This informationis displayedfor the therapist(Fig. 4). Theprogramissuesa warningif thetherapistselectsa completedfield (whoseprescribedtotalshave beenreached)or asupercededfield.

Thedose-to-daterecordsfor all fieldsarewritten out to a disk file at theendof eachtreatmentrunso the informationis not lost if theprogramshutsdown. Eachtime the programrestarts,it readsthisfile.

Thecontrolprogramappendsa recordto a treatmentrecordfile eachtime the therapy beamturnson or off, andat the endof eachtreatmentrun. Eachrecordstoresall of the pertinentmachinestateat that moment,including the prescribedandactualsettingvalues,calibrationfactorvalues,theelapsedtimeandaccumulateddosefor therun, thecurrentlyselectedpatient,field andoperatoron duty, etc.

Thesameuniqueidentifier for eachtreatmentfield is usedin the treatmentplanningprogram,theprescriptionfile anddose-to-datefile, andthetreatmentrecords.Thismakesit possibleto checkforerrorsby comparingsuccessive stepsin thetreatmentprocessfrom planningthroughdelivery. Wecall thisend-to-endchecking.

Whenpatientscompletetheir courseof treatment,their recordsareremovedfrom theprescriptionfile anddose-to-datefile andarestoredin a permanentarchive on disk. All treatmentrecordsarealsostored.Thereis enoughcapacityin thediskfile systemto storemany yearsof recordson-line.

Thetherapy controlprogramalsowritesa log thatrecordspertinenttreatmentandmachineevents.At theoperator’scommandtheprogramcanwriteoutfilesshowing therecentmessagetraffic among

9

thenetworkedcontrolcomputers.Thesecanbeusefulfor machinemaintenanceandtroubleshoot-ing. They arealsokepton-linepermanently.

5 Inter nals

In this subsectionwe describethesysteminternalswhich areonly visible to engineers:theoverallarchitectureandthecomponents.Detailsappearin theoperationsmanual[9].

Long productlife andeaseof maintenanceandupgradesareanoverriding concern.Customsoft-ware developmentis so laboriousand costly that we cannotafford to rewrite the entire controlsoftwareevery few years.Theentiresystemdesignwasvery muchdrivenby our needto postponeobsolesence.

5.1 Network-basedhardwareand softwarearchitecture

We chosea control systemarchitecturecomposedof several computersconnectedby a network(Fig. 2). This confersseveraladvantages:It easesdevelopmentandmaintenancebecausethema-chine can be operated(in somemodes)even when someof the computersare disconnectedorinoperable.It providesflexibility in locatingequipment.It postponesobsolesencebecausewe canperformfutureupgradesin stages,replacingcomponentsoneat a time. We hopethat thecostandeffort of occasionallyreplacingcomponentsand(rarely) rewriting (small) portionsof the customsoftwarewill bemuchlessthantheinitial costandeffort of creatingthenew controlsystem.

At this writing thecontrolsystemincludeseightnetworkedcomputers(not countingthetreatmentplanningcomputers).Eachcomputerexecutesits own controlprogramandcommunicateswith theothersby exchangingmessagesover thenetwork.

TheX terminal (actuallya kind of computer)providestheoperator’s keyboardandvideo display.The therapycontrol computerexecutesourcustomtherapy controlprogram.Thehostprovidesthefile systemthatstorestheexecutablecontrolprogramfilesandall thedata,includingtheprescriptionfile derivedfrom treatmentplans.Thesecomputersreplacea singlemastercomputerthatprovidedall threefunctionsin theoriginal controlsystem.

Five morecomputerssenseandcontrol thetherapy equipment(relays,motors,ion chambersetc.):the leaf collimator controller (LCC), the dosemonitor controller (DMC), the treatmentmotioncontroller (TMC), andtwo programmablelogic controllers (PLCs).ThePLCshandlesingle-pointsensorsandcontrols(limit switches,pushbuttons,lamps)anda few analogsignals.They replaceapartof thedigital input/outputsystemof themastercomputerin theold controlsystem.TheLCC,

10

CONTROL SYSTEM COMPUTERS

XTERMINAL

PLC1 PLC2 DMC TMC LCC THERAPYCONTROL..

HOST

.

PRIVATE NETWORK

Control room Power supply room

Department offices

HOSPITAL NETWORK

(OTHERCOMPUTERS) (ETC. ...)

.

TREATMENTPLANNING

PROGRAMDEVELOPMENT

CLUSTERSERVER

RADIATION ONCOLOGY DEPARTMENT COMPUTERS

Figure2: Network

11

DMC andTMC areretainedfrom theold controlsystem.

Eachcomputeris largely autonomousandcancontinueto performits essentialfunctionseven ifcontactwith theothersis lost. Thesafetyof thetherapy machinenever dependson messagesbeingreceivedwithin someparticulardeadline,or beingreceivedat all. Eachcomputercandetectcom-municationerrorsor timeoutsin theothersandrespondappropriatelyby indicatingtheproblemandplacingits local controlsin asafestate.Thenetwork is usedto sharedataandcoordinateactivities,to make progresswhile local controlsensuresafety. Two or more computersmustcooperatetobegin any potentiallyhazardousoperationbut eachcomputerby itself canreturntheequipmentto asafestate.For examplethetherapy controlcomputermustloadtheDMC with theprescribeddoseandcommandit to closeits relaysin orderto turn on thetherapy beam.After that,theDMC itselfopensits relays(forcing thebeamoff) whenit detectsthat theprescribeddosehasbeendeliveredor anerrorhasoccurred.

Thecontrolsystemcontinuesworking if thehostshutsdown or becomesinaccessible.Thetherapycontrol programstoresall datain programmemoryandonly readsor writes files whennew databecomeavailable. If thecontrolprogramis unableto accessthehostit continuesrunningwith thedataalreadyin memoryandnotifiesthe operator. The operatorcancommandthe programto tryagainwhenthehostbecomesaccessible.

We chosea centralizedarchitecturewherethe therapy control computeractsasmasterandsendscommandsto all theothers,which respondonly to themaster. This is a softwaredesigndecision;thenetwork supportsmessagesamongany computers.

Thecontrol computersandthehostcommunicateover a privatenetwork that is separatefrom thehospitalnetwork (Fig. 2). This providessecurityandminimizesnetwork congestion.Thehostisalsoconnectedto thehospitalnetwork soit cancommunicatewith thetreatmentplanningprogramandtheotherdatamanagementprograms.

5.2 Selectinghardware and softwareproducts

Having decideduponthe overall network-basedarchitecture,our next taskwasto selectparticu-lar hardwareandsoftwareproducts(we usetheword “products”broadlyto includeprogramminglanguagesandsoftwareprotocols,anditemsavailableat no costfrom academicandresearchinsti-tutions).

To avoid obsolesence,we choseproductswhicharenow widely used,appearto have a long future,andarelikely to bereplacedby functionallysimilar products.Wherepossible,we choseproductsthat areavailablefrom several manufacturersandthat conformto somevendor-independent stan-dard.To obtainreliability andstability, we choseproductswhichhave alreadybeenin wideusefor

12

many years,so theworstdefectshave beenshaken out andthe remaininglimitations arewell un-derstood.Wheretherewasachoicebetweenasimpleproductandamorecomplex one,we choosethe simpler. Wherea productoffers a large andcomplex featureset,we limit our useto a stable(older, betterunderstood)subset.We avoid productswhich seemoverly complex or which mightrequireexcessivemaintenance.Thisshouldreducethenumberof failuremodesandalsoreduceourdependenceonparticularsuppliers.

Thenetwork is Ethernethardwarewith TCP/IPsoftware[39] (at this writing theLCC, DMC andTMC areconnectedusingseparateRS232cables).Thehostcommunicateswith the therapy con-trol computerusingNFS (network file system)[39], a standardsoftwareprotocol. NFS enablesprogramsto be written asif all files wereattachedlocally; the actuallocationof the files on thenetwork is specifiedin a configurationfile that the programreadswhenit startsup. TCP/IPandNFS arenow universallysupportedby manufacturersso almostany recentmodelworkstationorpersonalcomputercouldbeusedasthehost6. Theconsolecomputeris anX terminal7, acomputerconfiguredby its manufacturerto displaygraphicsexpressedin X, anotherstandardprotocol[35](mostworkstationsandpersonalcomputerscouldalsobesoconfigured).Thetherapy controlcom-puteris asingle-boardcomputerfrom asemiconductormanufacturer8. It hasnokeyboard,display,or disks,but hasonboardRS232portsandanEthernetnetwork interface.It hasanindustrystandardsize,shapeandedgeconnector(VME bus[28]) soit canbehousedin a genericcabinet.ThePLCsareindustrialprogrammablelogic controllers9. The LCC, DMC andTMC wereprovided by thecyclotronmanufacturer.

Most of our programmingeffort wasdevotedto thetherapy controlprogram.Theprogramis writ-ten in C [24], using only universally supportedstandardfeaturesand libraries,except for a fewwell-encapsulatedmodulesthatusethe (alsowidely supported)Xlib library for X graphics[31]and(proprietary)operatingsystemlibrariesfor tasking,synchronization,anddevice control. Thetherapy control computerrunsa real-timeoperatingsystem[41] 10, which providesdeterministictiming andis muchsmallerandsimplerthana generalpurposeoperatingsystemsuchasUnix orWindows.

Wewroteall thecode“by hand”.Theprogramdoesnot includeany databaseor graphicsproducts.Suchproductscanbe complex andoften requireextensive operatingsystemsupport,which tendsto producea largeprogramthat is difficult to analyze.Moreover, theseproductsoftenchangeovertimeasnew versionsarereleased.Thiscanmake maintenancedifficult.

We alsowrotethePLC programsin ladderlogic notation,usinga languageprocessorprovidedbythePLCmanufacturer. Theprogramsfor theothercomputerswereprovidedby theirmanufacturers.

6At this writing thehostis a Hewlett PackardB160workstationrunningtheHP-UX 10.20operatingsystem.7TektronixXP217C8MotorolaMVME167-004Bwith a 25MHZ 68040processorand32MB memory9ModiconQuantumseries,SchneiderElectric,Inc.

10VxWorks,Wind River SystemsInc.

13

6 Developmentmethod

In this subsectionwe describethedevelopmentmethodusedto design,code,analyzeandtestthetherapy controlprogram.

Programmingis notoriouslyfallible. It is typical for seriouserrorsto escapedetectionin testing.Errorsin a therapy machinecontrol programhave causedfatal accidents[27, 26]. Finding bettermethodsfor preventinganddetectingerrorsis anactive areaof researchandcontroversy. We de-cidedto try formalmethods: expressthedesignin mathematics(thisis calledaformalspecification),andusemathematicalanalyses(theoremproving, modelchecking) to detecterrorsand(eventually)demonstratecorrectness.As far aswe know, oursis the first project to apply formal methodsinradiationtherapy, althoughthereareexamplesin otherindustries[6].

In particular, we hopedto demonstratethat thedetaileddesignsatisfiesthecentralsafetyrequire-ment: thebeamcanonly turn on (or remainon) whentheactualsetupof themachineconformstothestoredprescriptionselectedby theoperator.

6.1 Writing the requirements

Therequirements[16, 17,12] expressthepropertiesthat thesystemmusthave to beacceptabletoits users,expressedin proseanddiagramsthat they canunderstandandcritique. Theauthorsandreviewersincludethephysicistwho definedthephysicalandclinical requirementsfor theoriginalmachine,engineerswho installedand maintain the machine,and clinical usersof the machine.Writing therequirementswasamajorportionof thewholeprojecteffort, not justapreliminary.

6.2 Writing the formal specification

Theformal specificationis a collectionof mathematicalformulasthatexpressthe requirementsasconstraintson a setof statevariables. It is expressedin Z [38, 7], a machine-readablenotationfor logic, settheoryandarithmetic.Thefull text appearsin [13]; excerptsandcommentaryappearin [18, 7, 19, 10].

Thesetof statevariablesrepresentsall pertinentfeaturesof thetreatmentmachineryandthetreat-mentsession.Therearestatevariablesfor theprescribedandactualvaluesfor all thesettings,thestatusof operationsin progress,thepatientandfield identificationusedto accessstoredprescrip-tions, etc. We identified410 scalarstatevariables(Table2). Z providesconstructsthat make itconvenientto dealwith largenumbersof variables.

14

Wewroteformulasto expresstheconstraintsthatmusthold amongthevaluesof thestatevariablesat all times. Theseformulasarecalled invariants. All safetyrequirementscanbe expressedasinvariants. Invariantsevaluateto true in situationsthat satisfytheconstraintsandfalseotherwise.TheEnglishparaphraseof oneinvariantsays:“If thebeamis on,all leavesarewithin toleranceoftheir prescribedvalues”. A conditionthatcausesan invariantto evaluateto falseviolatesa safetyrequirement11.

The invariantsexpresspreciselywhat it meansfor the programto be in a safestate. Most of thevalueaddedto theprojectby theformal specificationinheresin theinvariantsbecausethey expressinformationthatisnotpresentin theprogramandcannotbeinferredfromtheprogram.Theprogramcodeexpressesa greatmany statetransitions.With greateffort, we might be ableto analyzethecodeto determinethesetof reachablestates.But this cannottell usif thereachablestatesaresafe.The programmight be ableto reachan unsafestate,dueto a designoversightor a programmingerror. In fact, the safetyanalysisis actuallynothingmorethancheckingthat the setof reachablestatesis a subsetof thesetof safestates.For this we needanexplicit descriptionof thesafestateswhich is independentof theprogram,andthatis whattheformal specificationprovides.

In addition to the invariants,we alsowrote formulasto expressthe statetransitions. Unlike theinvariants,theseformulascorrespondcloselyto theprogramcode.However they arewritten in thesamemathematicalnotationas the invariants,and they aremoreconcisethancodebecausetheyonly modelits effects,not its details.Eachoperationis describedby a formulacalleda precondi-tion which describesthe stateswherethe operationcanbegin andanothercalleda postconditionwhich describesthestateafter theoperationcompletes(thepostconditioncanbea functionof theprecondition).Wedescribed105statetransitions.Wewrote2103linesof Z in all (Table2).

The structureof the formal specificationalsoexpressesthe modulardesignof the program. Webelieve thatwriting andrevisingtheformalspecificationhelpedusmakeaclearandconcisedesign.

6.3 Analysing the formal specification

To demonstratesafetywe mustshow thatevery reachablestateis safe,asfollows: First, show thattheinitial statesaresafe.Then,for eachstatetransition,show thatif its startingstateis safe,thenitsendingstateis safealso.That’sall. It is notnecessaryto considerthe(vast)collectionof all possibleprogramexecutions.We needonly considerthe initial state(trivial) andthenindividually analyzeeachof ourstatetransitions(tediousbut quitefeasible).Wecheckthateachtransitiondoesnot vio-lateany invariants.It is notnecessaryto explicitly considerall possiblevaluesof thestatevariablesbecausethetransitionsandtheinvariantsarebothrepresentedsymbolically(with variablesinsteadof explicit values). We needonly show that the formula that describesthe transitionimplies theformulathatexpressestheinvariants.This is usuallyastraightforwardexercisein thesimplification

11Theformulaparaphrasedif p thenq is falsewhenp is trueandq is false, andis true in all othersituations.

15

of logical expressions.It shouldbepossibleto automatemuchof this usinganautomatedtheoremprover, but we usedinspection(by eye) anda few pencil-and-papercalculations.Someexamplesappearin [19, 10]. Sincetheseanalyseswerenotautomated,they arefallible andrely onsubjectivejudgmentregardingwhereto concentratetheinspectioneffort.

Somepropertiesof a formalspecificationcanbecheckedautomatically. Wecheckedfor syntaxandtypeerrorsusinga tool [37] similar to a programminglanguagecompiler, andcheckedfor domainerrors (somewhatlike array-out-of-boundserrors)usinganautomatedtheoremprover [34].

We analyzedsomeof our design’s taskingandtiming properties[8] with anexhaustive simulationtechniquecalledmodelchecking [3]. Weexpressedportionsof ourdesignin aspecialprogramminglanguageusedby thechecker, writing a much-simplifiedversionof our programthatneverthelessexercisedcertainrequirementsof interest.Thenweexpressedthoserequirementsin anotherformalnotationcalledCTL that includestemporaloperatorssuchasuntil andeventuallyso it cancheckprogressproperties,not just invariance.The checker tool constructsthe (very large but finite) setof statesreachableby the (simplified) program,performinga simulationof all possibleprogramexecutions(including all possibleinterleavings of a multitaskingprogram). The tool checksthateachsimulatedexecutionpathsatisfiesthe requirementsexpressedin CTL. If it doesnot, it printstheentireexecutionpaththatcontainstheerror.

Theautomatedanalysesachieve completecoveragewithin their (limited) scope;in thatsensetheyareinfallible. However, the choiceof what to analyzeandthe judgmentthat the formal notationexpressesasufficiently accuratemodelof therealsystemis subjective andfallible.

6.4 Coding the program

The formal specificationalsoserved asthe detaileddesignfor mostof the code(but not all codewasformally specified,seeTable2). Weusednootherdesignnotation(besidesEnglish).Wecodedusingmethodsrecommendedin a textbook [7]. Usuallywe could implementeachZ paragraphinlessthana pageof C codeso it is easyto confirm by inspectionthat the codecorrectlyachievesthe intentof its specification.We performeda pencil-and-paperformal verificationof onepageofcode[18]. Detailsaboutthecodeandprograminternalsappearin theimplementationreport[11].

We hadonly limited accessto the therapy machine(which wasalreadyin use,runningundertheold control system),so we developedprogramversionsthat do not requireaccess(Table3). Thedemonstrationversionrunsonanordinarydesktopworkstation.Thesimulationversionexecutesonthesingle-boardcomputerwith thereal-timeoperatingsystem,but inputsandoutputsto thetherapyequipmentaresimulatedby stubroutinesthatreadandwrite files instead.A third versionexecuteson thetherapy machine.Mostof thecodeis thesamein all versions.

16

The programwas built up incrementallyand was undercontinualrevision. We recordedeveryaddition,revision andcorrectionto theprogramin achangelog (Table3)12.

6.5 Testingand evaluating the program

The formal analysesdescribedpreviously wereappliedto the formal specification,not the code.They wereintendedto revealdesignerrors,andcannotrevealcodingerrors.We usedcodeinspec-tionsandtestingto detecttheseerrors.

We distinguishtestingfrom evaluation. Testingis devotedto detectingerrorswhereprogrambe-havior violatesthe specification[20]. Evaluationis devoted to clarifying requirements,assessingusabilityandobtainingsuggestionsfor improvement.Most programuseduringdevelopmentwasevaluation,not testing;mostchangesto theprogramwereadditionsandimprovements,not correc-tions(Table3)13.

In thedemonstrationandsimulationstagesmosttestswereperformedautomaticallyby executingtestscripts:filesof simulatedoperatorkeystrokesandsimulatedinputsfrom thetreatmentmachin-ery. Usingscriptsensuresthat testsarerepeatable(andareeasyto repeat).The outcomeof eachtest is recordedin log files written by the programundertest. In the evaluationandacceptancetestphaseswe ranthetreatmentmachine(includingthenew controlprogram)in exactly thesameconfigurationasa therapistwoulduseto treatpatients.Thereforewe couldnotusescripts.Instead,testersworkedat thetherapy consolefrom awritten testplan.Sometestssimulatedequipmentandprogramfailuresduringtreatmentoperations(by substitutingjumpersfor relays,resettingcomput-ers,etc.).

7 Program sizeand other project metrics

The productsof the developmentincludedocumentationandassuranceevidence(testplansetc.),not just theprogramitself (Table1).

Our therapy control programis small, hasminimal dependenceon other products,and requireslittle operatingsystemsupport,so it shouldbe reliableandeasyto maintain. It comprises15,786lines of C programminglanguagecode(not countingcommentsandblank lines), divided into 96files (Table2). Of these,75 useonly ANSI standardC constructsand libraries; 4 moreusethe

12Thelog doesnotdistinguishchangesmadein thesimulationandevaluationstages(exceptcorrections).Theentryinthetable(742)is thetotal for bothstages.

13We begantheacceptancetestphasewhenwe consideredtheprogramfinished.We subsequentlydecidedon furtherrevisionssothetableshows bothchangesandcorrectionsin this phasealso.

17

PRODUCT SIZE

Requirements: overview [16] 106 pagesRequirements: user interface (chapters 2, 6–9 in [17]) 106 pagesRequirements: hardware and files [12] 131 pagesFormal specification (Z notation) [13] 129 pages (2103 lines)Scheduling model (Z notation) [8] 246 linesScheduling simulation (SMV model checker, CTL) [8] 423 linesProgram change logs 3144 linesTest data and scripts 30725 linesAcceptance test plan 42 pagesProgram code (C programming language) 15786 lines (96 files)Therapist’s Guide [15] 41 pagesOperations Manual [9] 125 pagesReference Manual [14] 233 pagesImplementation Manual [11] 70 pages

Table1: Developmentproducts(documentsandcode)

X graphicslibraries. Thesefiles werewritten andfirst testedon a general-purposeworkstation.Only 17 files usethereal-timeoperatingsystemlibraries;thesehadto bedevelopedon thecontrolcomputer. Weonly use32X library functions(outof morethan360provided[31]) and31operatingsystemfunctions(out of morethan1400provided [42]). The total sizeof theexecutableprogramfiles loadedinto thetherapy controlcomputeris 1,611,668bytes(1,611kilobytes,1.6megabytes):716,380bytesfor theoperatingsystem(includingnetwork support),502,429bytesfor X graphicssupport,and392,859bytesfor ourcustomtherapy controlprogram.

Our control software is much smallerandsimpler than typical applicationprogramsfor generalpurposecomputers,which often occupy several megabytesandarestrongly interdependentwithoperatingsystemsthatoccupy many megabytesmore.It is thoughtto beinfeasibleto analyzesuchcomplex systemsthoroughly, andmany errorsaredetectedby customersafterlong use.

Thanksto its smallsize,thetherapy controlprogramis fast. Theprogrambootsandcompletesitsinitialization sequencein about35 seconds.The entireprogramandall dataremainin computermemorysooperatorsalmostnever perceive delaysdueto computeractivity.

8 Operational experience

The new control systemwasput into operationin July 1999. At this writing (May 2001) it hasdeliveredover 9000fields(Table3). We have never deliveredanincorrecttreatment,andwe have

18

Category Formal specification in Z Code in Cvariables transitions lines files lines

Pervasive constants and types 0 0 55 6 491User interface (except graphics) 10 34 658 2 2058In-memory database 185 9 333 6 686Interlocking logic 114 2 188 2 474Process and event handling 4 1 40 19 776Low-level device control 14 18 375 13 2898Files and persistent data 65 13 186 13 1598Treatment sequence 18 28 268 2 1663Graphics (utilities) 0 0 0 5 1006Graphics (application-specific) 0 0 0 28 4136Total 410 105 2103 96 15786

Table2: Therapy controlprogram:sizeof formal specificationandcode.

never hadto reschedule(delay)a treatmentfor technicalreasons.Therapistsandotherstaff saythe new systemis a big improvementin convenienceandefficiency over the old system. It hasbeeneasyto revisetheprogramto improve efficiency andto correcta few errors.We have alreadyreplacedthreeof thenetworkedcomputers(bothPLCsandthehost).

8.1 Revisionsafter installation

In thefirst few monthsof operationwe mademany minor revisionsto thetherapy controlprogramto improve efficiency andusability, and to dealwith situationsnot anticipatedwhen the specifi-cationswerewritten (Table3). Someinvolved theuserinterface,othersdealtwith noisein analogsignals,errormessagesfrom thecontrollers,andtiming andinterleaving of controlleractivity. Nonerequiredextensive changesto thedesignor code.

We madeseveralchangesto thenetwork beforearriving at theconfigurationpicturedin Fig. 2. Atfirst thecontrolcomputerswereconnectedto asegmentof thehospitalnetwork andthedepartmentclusterserver wasalsothecontrolsystemhost. Operatorssometimesexperiencedappreciablede-lays whenthe control programattemptedto reador write files; during oneincident the programcrashed,duringanotherafile wascorrupted.Eventuallytheproblemwastracedto anintermittentlyfaulty device on the hospitalnetwork. We provided the control systemwith its own host and aprivatenetwork, wheretherearemany fewer devicesand(we hope)fewer failure modes. Sincethenwe have experiencedno network problems.Network reconfigurationsrequiredno changestothe therapy controlprogram,andno changesto theproceduresusedby therapistsat the treatment

19

Project phase Sessions ChangesName Environment Begun Days Fields total errors

Demonstration Desktop workstation Oct 1996 — — 965 126Simulation Single-board computer Jan 1998 — — 742 57Evaluation Therapy machine Feb 1998 42 582 ¨ 27Acceptance test Therapy machine Apr 1999 21 403 91 8Initial use Therapy machine Jul 1999 91 2015 35 6Routine use Therapy machine Nov 1999 370 7165 30 4

– Apr 2001

Table3: Experienceduringtestinganduse

planningworkstationsor thetherapy console.

RecentlywereplacedbothPLCswith newermodelsthatuseEthernet(insteadof RS232)andadif-ferentcommandprotocol.This requiredchangingfour sourcefiles in thetherapy controlprogram.

8.2 Err or detectionand correction

Thenumberof errorsdiscoveredandcorrectedhasdeclinedin eachprojectstage(Table3). Eighterrorswerediscoveredduringacceptancetesting.Tenerrorsescapeddetectionduringdevelopmentandwerediscoveredby therapistsor physicistsduring actualuse. At this writing no errorshavebeendiscoveredin the lasteight months;this suggeststhe programis now nearlyerror free. Theprogramhasa deliverederrordensityof 10/15,786,lessthanoneerrorper thousandlinesof code(KLOC). Typical commercialsoftware productsare deliveredwith one to ten errors/KLOC[2].We deliveredour earliertreatmentplanningsystemwith 2.1errors/KLOC[20]. In thatprojectwealsouseddetailedproserequirementsandthoroughtesting(but no automatedtestscripts),so weconcludethat formal methodsand( andpossiblytestautomation)contributedto the improvementin quality.

Our efforts to preventerrorsconcentratedon preventingthemostseriousincidents:settingup themachineincorrectly, or disablingthe machineso it could not completea treatment.No suchin-cidentshave occurredduringacceptancetestingor use. Themostseriousincidentsthatdid occurinvolvedrecordkeeping,wheretheprogramrecordedthewrongnumberof treatmentsor thewrongdosein the in-memorydose-to-daterecords.Therapistsnoticedtheerrorson thefirst daywhenadiscrepancy appeared(they alsocouldhave beendiscoveredby reviewing treatmentrecords).

On several occasionsthe programhashaltedspontaneously(crashed). Threesuchincidentsoc-curredduringpower or network disturbances.Twelve occuredat theendof a run, shortlyafter the

20

beamturnsoff. This suggestsa programmingerrorbut we have not discoveredit (theseincidentsoccurlessthanoncea month,lessthanonceevery 770fields). Suchincidentswereanticipatedinthe systemdesign. Therewasno hazardandoperationsresumedpromptly andwithout difficultywhentheprogramwasrestarted.

9 Conclusions

A therapy machinecontrol systemcanbeconstructedlargely from standard(vendor-independent)hardwareandsoftwarecomponentsconnectedby a network. This easesdevelopmentandmain-tenanceandpostponesobsolescence.Operationscanbe maderobust andsafedespiteoccasionalfailuresin thenetwork or individual components.

A modernradiationtherapy machinecanhave a simpleandefficient userinterface,provided thatdesignerspaycarefulattentionto theoperators’tasks,sothey caneliminateunnecessarystepsanddistractingelements.

Separatingcontrol functionsfrom datamanagementfunctionsmakesit possibleto write a controlprogramwhich is small,fast,andfeasibleto analyzethoroughly.

Closeintegrationwith the treatmentplanningsystemtogetherwith automatedrecordkeepingcanhelpensureaccurateandcorrecttreatments.Providing eachfield with thesameuniqueidentifierintreatmentplanning,machinesetup,andtreatmentrecordsmakesit possibleto checkfor errorsbycomparingsuccessive stepsin thetreatmentprocessfrom planningthroughdelivery. Much of thischeckingcouldbeperformedautomatically.

Formalsoftwaredevelopmentmethodsincludingautomatedanalysescanassistin creatinga con-cise, correctdesignandcanhelp prevent anddetectprogrammingerrors. Formal methodshavepotentialfor introducingadditionalautomationinto thedevelopmentprocessthatmight save timeandimprove quality further.

21

References

[1] Mary Austin-Seymour, RichardCaplan,KennethRussell,GeorgeLaramore,JonJacky, PeterWootton,SharonHummel,KarenLindsley, andThomasGriffin. Impactof a multileaf colli-matoron treatmentmorbidity in localizedcarcinomaof theprostate.InternationalJournal ofRadiationOncology Biology Physics, 30(5):1065–1071, Dec1994.

[2] Boris Beizer. Software SystemTestingandQuality Assurance. VanNostrandReinhold,NewYork, 1984.

[3] E. Clarke, O. Grumberg, andD. Long. Verificationtools for finite-stateconcurrentsystems.In J. W. De Bakker, W.-P. de Roever, and G. Rozenberg, editors, A Decadeof Concur-rency, pages124–175,Noordwijkerhout,The Netherlands,1993.REX School/Symposium,Springer-Verlag.LectureNotesin ComputerScience,vol. 803.

[4] L. R. Dalesio, M. R. Kraimer, and A. J. Kozubal. EPICS architecture. In C. O. Pak,S. Kurokawa, andT. Katoh, editors,Proceedingsof the InternationalConferenceon Accel-erator andLarge ExperimentalPhysicsControl Systems, pages278–282,1991. ICALEPCS,KEK, Tsukuba,Japan.

[5] B. A. Fraas,D. L. McShan,M. L. Kessler, G. M. Matrone,J. D. Lewis, andT. A. Weaver.A computer-controlledconformalradiotherapy system.I: Overview. InternationalJournal ofRadiationOncology Biology Physics, 33(5):1139–1157, 1995.

[6] SusanGerhart,Dan Craigen,andTed Ralston. Experiencewith formal methodsin criticalsystems.IEEE Software, 11(1):21–28,Jan.1994.

[7] JonathanJacky. TheWay of Z: Practical Programmingwith Formal Methods. CambridgeUniversityPress,1997.

[8] JonathanJacky. Analyzingareal-timeprogramwith Z. In JonathanBowen,AndreasFett,andMichaelHinchey, editors,ZUM ’98: TheZ Formal SpecificationNotation. EleventhInterna-tional Conferenceof Z Users,Springer-Verlag,1998.LectureNotesin ComputerScience.

[9] JonathanJacky. Clinical neutrontherapy systeminstallationandoperations.TechnicalReport99-08-01,Departmentof RadiationOncology, Universityof Washington,Box356043,Seattle,Washington98195-6043,USA, August1999.

[10] JonathanJacky. Lessonsfrom theformaldevelopmentof a radiationtherapy machinecontrolprogram.In MichaelG. Hinchey andJonathanP. Bowen,editors,Industrial-StrengthFormalMethodsin Practice, pages185–206.Springer-Verlag,1999.

[11] JonathanJacky. Clinical neutrontherapy systemimplementation. TechnicalReport2001-03-01,Departmentof RadiationOncology, University of Washington,Box 356043,Seattle,Washington98195-6043,USA, March2001.

22

[12] JonathanJacky, MichaelPatrick, andRuediRisler. Clinical neutrontherapy system,controlsystemspecification,PartIII: Therapy consoleinternals.TechnicalReport95-08-03,RadiationOncologyDepartment,Universityof Washington,Seattle,WA, August1995.

[13] JonathanJacky, MichaelPatrick,andJonathanUnger. Formalspecificationof controlsoftwarefor aradiationtherapy machine.TechnicalReport95-12-01,RadiationOncologyDepartment,Universityof Washington,Seattle,WA, December1995.

[14] JonathanJacky andRuediRisler. Clinical neutrontherapy systemreferencemanual.TechnicalReport99-10-01,Departmentof RadiationOncology, Universityof Washington,Box 356043,Seattle,Washington98195-6043,USA, October1999.

[15] JonathanJacky andRuediRisler. Clinical neutrontherapy systemtherapist’s guide.TechnicalReport99-07-01,Departmentof RadiationOncology, Universityof Washington,Box 356043,Seattle,Washington98195-6043,USA, July1999.

[16] JonathanJacky, RuediRisler, Ira Kalet, andPeterWootton. Clinical neutrontherapy system,control systemspecification,PartI: Systemoverview andhardwareorganization. TechnicalReport90-12-01,RadiationOncologyDepartment,University of Washington,Seattle,WA,December1990.

[17] JonathanJacky, RuediRisler, Ira Kalet, PeterWootton,andStanBrossard.Clinical neutrontherapy system,control systemspecification,PartII: Useroperations.TechnicalReport92-05-01,RadiationOncologyDepartment,Universityof Washington,Seattle,WA, May 1992.

[18] JonathanJacky andJonathanUnger. FromZ to code:A graphicaluserinterfacefor aradiationtherapy machine.In J.P. BowenandM. G. Hinchey, editors,ZUM ’95: TheZ FormalSpecifi-cationNotation, pages315–333.Ninth InternationalConferenceof Z Users,Springer-Verlag,1995.LectureNotesin ComputerScience967.

[19] JonathanJacky, JonathanUnger, MichaelPatrick,David Reid,andRuediRisler. Experiencewith Z developinga controlprogramfor a radiationtherapy machine.In JonathanP. Bowen,MichaelG. Hinchey, andDavid Till, editors,ZUM ’97: TheZ Formal SpecificationNotation,pages317– 328.TenthInternationalConferenceof Z Users,Springer-Verlag,1997. LectureNotesin ComputerScience1212.

[20] JonathanJacky andCherylP. White. Testinga3-D radiationtherapy planningprogram.Inter-nationalJournalof RadiationOncology, Biology andPhysics, 18:253–261,January1990.

[21] Ira J. Kalet, JonathanP. Jacky, Mary M. Austin-Seymour, SharonM. Hummel,Kevin J. Sul-livan, andJonathanM. Unger. Prism: A new approachto radiotherapy planningsoftware.InternationalJournal of RadiationOncology, Biology andPhysics, 36(2):451–461,1996.

[22] Ira J. Kalet, JonathanP. Jacky, RuediRisler, Solveig Rohlin, andPeterWootton. Integrationof radiotherapy planningsystemsandradiotherapy treatmentequipment:11yearsexperience.InternationalJournal of RadiationOncology, Biology andPhysics, 38(1):213–221,1997.

23

[23] C. J.KarzmarkandNeil C. Pering.Electronlinearacceleratorsfor radiationtherapy: History,principlesandcontemporarydevelopments.Physicsin MedicineandBiology, 18(3):321–354,May 1973.

[24] BrianW. KernighanandD. M. Ritchie.TheC ProgrammingLanguage. Prentice-Hall,secondedition,1988.

[25] G.E.Laramore,J.M. Krall, T. W. Griffin, W. Duncan,M. P. Richter, K. R.Saroja,M. H. Maor,andL. W. Davis. Neutronversusphotonirradiationfor unresectablesalivary glandtumors:final reportof an RTOG-MRCrandomizedclinical trial. InternationalJournal of RadiationOncology, Biology andPhysics, 27(2):235–240,1993.

[26] Nancy G. Leveson.Safeware: SystemSafetyandComputers. Addison-Wesley, 1995.

[27] Nancy G. LevesonandClark S. Turner. An investigationof theTherac-25accidents.IEEEComputer, 26(7):18–41,July1993.

[28] Yu-chengLiu. TheM68000MicroprocessorFamily: Fundamentalsof AssemblyLanguageProgrammingandInterfaceDesign. Prentice-Hall,1991.

[29] G. S.Mageras,Z. Fuks,J.O’Brien, L. J.Brewster, C. Burman,C. S.Chui,S.A. Leibel,C. C.Ling, M. E.Masterson,R.Mohan,andG.J.Kutcher. Initial clinical experiencewith computer-controlledconformalradiotherapy of theprostateusinga 50-MeV medicalmicrotron. Inter-nationalJournalof RadiationOncology Biology Physics, 30(4):971–978,1994.

[30] G. S.Mageras,K. C. Podmaniczky, andR. Mohan.A modelfor computer-controlleddeliveryof 3-dconformaltreatments.MedicalPhysics, 19(4):945–953,1992.

[31] AdrianNye.Xlib ProgrammingManual. O’Reilly andAssociates,Inc.,Sebastopol,CA, 1988.

[32] ErosPedroni,ReinhardBacher, HansBlattmann,TerenceBohringer, Adolf Coray, AntonyLomax, Shixiong Lin, Gudrun Munkel, Stefan Schweib, Uwe Schneider, and AlexanderTourovsky. The 200-MeV protontherapy projectat the Paul Scherrerinstitute: Conceptualdesignandpracticalrealization.MedicalPhysics, 22(1):37–53,January1995.

[33] RuediRisler, Juri Eenmaa,JonathanP. Jacky, Ira J. Kalet, PeterWootton,andS. Lindbaeck.Installationof thecyclotronbasedclinical neutrontherapy systemin Seattle.In Proceedingsof theTenthInternationalConferenceon Cyclotronsand their Applications, pages428–430,EastLansing,Michigan,May 1984.IEEE.

[34] Mark Saaltink.TheZ/EVESsystem.In JonathanP. Bowen,MichaelG. Hinchey, andDavidTill, editors,ZUM ’97: TheZ Formal SpecificationNotation, pages72 – 85. TenthInterna-tional Conferenceof Z Users,Springer-Verlag, 1997. LectureNotesin ComputerScience1212.

[35] R.W. ScheiflerandJ.Gettys.TheX window system.ACMTransactionsonGraphics, 5(2):79–109,1986.

24

[36] J. M. Slater, D. W. Miller, andJ. O. Archambeau.Developmentof a hospital-basedprotonbeamtreatmentcenter. InternationalJournal of RadiationOncology, Biology and Physics,14(4):761–775,1988.

[37] J. M. Spivey. The f UZZ Manual. J. M. Spivey ComputingScienceConsultancy, Oxford,secondedition,July1992.

[38] J.M. Spivey. TheZ Notation:A ReferenceManual. Prentice-Hall,New York, secondedition,1992.

[39] W. RichardStevens.TCP/IPIllustrated,Volume1: TheProtocols. AddisonWesley, 1994.

[40] Martin S. Weinhous,JamesA. Purdy, andConradO. Granda. Testingof a medicallinearaccelerator’s computer-controlsystem.MedicalPhysics, 17(1):95–102,Jan/Feb1990.

[41] Wind RiverSystems,Inc.,Alameda,California. VxWorksProgrammer’s Guide5.3.1, 1997.

[42] Wind River Systems,Inc., Alameda,California. VxWorks ReferenceManual 5.3.1, 1997.Edition1.

25

(drawing goeshere)

Figure3: Neutrontherapy machine

26

Figure4: Field list screen

27

Figure5: Summaryscreen

28

Figure6: Leafcollimatorscreen

29

Figure7: Dosecalibrationscreen

30