Brand, H

Essel, H G

Hardel, H

Hoffmann, J

Kurz, N

Ott, W

Poppensieker, K

Richter, M

Yang, J

CERN Document Server

HEAVY ION CANCER THERAPY @ GSISLOW CONTROL AND ONLINE MONITORINGH. Brand, H.G. Essel, H. Hardel, J. Hoffmann, N. Kurz, W. Ott, K. Poppensieker, M. Richter,J. Yang, GSI, Darmstadt, GermanyAbstractThe software control system for the therapy treatmentconsists of three parts. The operator interface based onFactoryLink ECS1 used as colourgraphic system, theFrontend-Daemon [1] controlling the hardware and theTherapy Online Monitor TOM. The treatment facility isdesigned to be operated by a medical assistant. FactoryLink ECS is used to provide a graphical userinterface to the operator, to survey alarm conditions andto provide access to a relational database.The Frontend-Daemon provides an object orientedaccess to the distributed control hardware. Long lastingcommands and the readout are implemented as POSIX-Threads.The Therapy Online Monitor TOM displays therequested and measured data, positions and particleintegrals point by point, in realtime on a second screen.Fourtyeight patients were successfully treated withthis system at GSI since December 1997.1  SOFTWARE AND OPERATINGSYSTEMFigure 1 shows on the left side the GUI and on theright side the frontend system connected by RPC2channels.Figure 1:  Client-server control system structureThe operator interface based on FactoryLink ECSruns on an IBM RISC-workstation under AIX 4.2. TheFrontend-Daemon, build from an extended C++ class                                                       1  Copyright US Data Corporation2 Remote Procedure Calllibrary, runs on an Eltec E7 processor in the VMEcontrol crate  under Lynx 2.2.2  FRONTEND SYSTEM2.1 Class hierachyThe daemon is designed as an RPC-server to configureand to access the associated hardware. Each hardwaremodule is represented by an instance of a class whichmodels its characteristics. Different channels in a singlemodule, e.g. HVModule are similarly represented byHVChannel objects as shown in figure 2.Figure 2: UML3 Class Diagram for High Voltage System2.1 ConfigurationThe configuration for all objects is defined in anASCII file of following format: Classname Objectname[Parameter] .- This file is read during startup or on request and alldefined objects are instantiated.- Then all objects are requested to read their ownparameter from the file.- Then all objects are requested to initializethemselves including their associated hardware.2.2 RPC ExecutionThere are two methods to execute remote procedurecalls:- Actions, like VME operations which needs onlylittle time are executed immediately.                                                       3 Unified Modeling LanguageRPC-Client of Frontend-Daemon andRPC-Server for Frontend-DaemonRPC-Server for FactoryLink andRPC-Client of FactoryLinkRunning underLynxOS in VMERunning underAIX 4.2DataChannelHardware-ModulereadSurveyreportChangesrefreshOperatorFrontend-DaemonHardware accessDatabaseFactoryLinkInteractionrpcToVMErpcFrVMESQLFrontend-DaemonVMECtrlVMECtrlE7HVChannel HVModuleHVStruckFiFoRS232SurveySurveyableInternational Conference on Accelerator and Large Experimental Physics Control Systems394International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italy- Actions, like changing the high voltage ofmodules connected via RS232, which need longtime are executed asynchronously. The RPCreturns immediately. The alarm handler of thesupervising software will then be informeddirectly in case of an error.2.3 SurveySeveral Survey objects, implemented as POSIX-Threads, are configured as RPC-clients of  FactoryLink.They request the associated module objects, i.e.HVModule, to  refresh their information about the stateof the hardware and the DataChannel objects, i.e.HVChannel, to report only changes to FactoryLinkwhich exceed configured limits. Data is converted tophysical units where necessary.3  OPERATING INTERFACE3.1 FactoryLinkFactoryLink is a collection of asynchronously workingtasks connected through the Real Time Data Bus(RTDB), which is shared memory accessible through theFactoryLink kernel (see Figure 3). The activities are databut not event driven. Commands are sent to theFrontend-Daemon via the FLout task. Data is receivedfrom the daemon via the FLin task. Alarms and trendingdata like pressure, temperature and voltages of theionisation chambers, are stored to a database via theHistorian task. The contents of the databases aredisplayed on operator request.Figure 3: FactoryLink structure3.2 Graphical User InterfaceThe graphical user interface consists of two mainwindows.- The “Information”-window in the upper part ofFigure 4 provides an efficient general overview overthe system, i.e. accelerator, scanner magnets,ionisation chambers, gas-system, PET-camera,patients couch, electronics and network.Components in active alarm conditions are markedwith red colour.- Detailed informations, database contents, logfilesand descriptive alarm messages are displayed in the„Operating“-window on request in the lower part ofFigure 4.Four levels of access control are implemented:- Everyone is allowed only to view all informations.- Operators are allowed to operate the system.- Engineers are permitted to change setup parameter.- The Supervisor has full control.4  TREATMENT PROCEDUREAfter system startup and test the engineer releasescontrol to the operator, medical physicists and medicalassistance.The medical physicists performs the daily tests,interlock tests and dose calibration, in the morning andtreatment plan verification at least once before thepatient is treated for the first time and when everneccessary.The medical assistance performs the patient treatment.A treatment plan is identified by a unique combinationof name, date and patients barcode. The current plan isselected from a list of valid plans for the current patient.and it is then downloaded automatically. When thepatient is lying on the couch, figure 6, and the position isverified using x-rays the treatment is started. The startprocedure checks for data consistency and active alarmsand releases control to the interlock system if everythingis ok. The progress of the treatment is shown in the„Operating“-window and in the TOM display, figure 5,on a second screen. After treatment is finished or in caseof an interlock the measured data is stored on disk andthe last treatment point is modified in the current plan asdefault for the starting point when treatment iscontinued.REFERENCES[1] H. Butler, D.R. Myers, W. von Rüden and J. Yang,“Beamline Operation using an Industrial ControlSystem and Distributed Object-Oriented HardwareAccess”, IEEE Trans. on Nucl. Sc., Vol. 41, No. 1,February 1994.[2] H. Brand, H.G . Essel, H. Hardel, J.Hoffmann, N.Kurz, W. Ott, M.Richter, “Therapy Slow ControlSystem, Data Analysis and Online Monitoring ”,GSI Scientific Report 1997[3] E. Badura et al., “Control System for CancerTherapy with a Heavy Ion Beam at GSI”, to bepublished in IEEE Trans on NP 1999RPC-Client ofFrontend-DaemonDatabaseTrendingOperatorHistorianSQLGUIAlarmDatabase-LoggerDataBase-BrowserRTDBFLoutFLinFrontend-DaemonrpcToVMErpcFrVMERPC-Client forFrontend-Daemon395Figure 4: Graphical User InterfaceFigure 5: TOM Online Monitor Display Figure 6: Patient on Couch.396

Heavy Ion Cancer Therapy @ GSI Slow Control and Online Monitoring

Heavy Ion Cancer Therapy @ GSI Slow Control and Online Monitoring

Abstract

Similar works

Full text

Available Versions

CERN Document Server