RIKEN-RIBF CONTROL SYSTEM
T. Tanabe, Y. Watanabe and M. Kase, RIKEN, Saitama, Japan

Abstract
Design issues on control system for the Radioactive
Isotope Beam Factory (RIBF) project at RIKEN arediscussed. They include a partial grade-up plan for theexisiting facility with EPICS, a R&D on CORBA/IIOP
based system using VME/CPCI and future development
plan for MUSES.

1 INTRODUCTIONRIKEN-RIBF project is an expansion of the exisitng
RIKEN acclerator research facility (RARF).
It iscomprised of two major facilities. The first part consistsof an intermediate ring cyclotron (IRC), asuperconducting ring cyclotron (SRC) and two RI beam
separators (Big RIPS). The second one is named MultiUse Experimental Storage rings (MUSES) project, whichcontains an accumulator cooler ring (ACR), a booster
synchrotron ring (BSR), a 300-MeV electron linac (elinac) ans double storage ring (DSR). Figure 1 shows abird’s eye view of the RIBF facilities. The first phase will
be completed by 2002 and MUSES is projected to be inoperation in 2005 depending upon the budget approval.

The RARF control system is centralised on a small
main-frame (MF) computer (Melcom M60) which
controls all the aspects of machine controls through
CAMAC and proprietary field-bus (SUMITOMO CIMDIM), MMI and DB. Similarly constructed injector
controls are almost independent from those for the mainring.

2.2 Partial Upgrade with EPICS
There is an urgent need to quickly replace M60, due toits high annual operational expense, with something
proven and reliable. EPICS was chosen because of its
proven reliability and fast-development-feature with one
CPU system. A high-end Power PC (MPC750-300MHz)
based VME computer will entirely replace M60 whileleaving all the CAMAC systems and below. This upgradeis planned to be completed by May 1999.

2.3 Future Major Upgrade and Integration
with RIBF
This partial upgrade is considered the first step toundertake a major overhaul on the existing facility and its
integration of RIBF control system. CIM-DIM interface
was specifically designed for RARF and there are no
more parts left for maintenance.
Therefore, thereplacement of CIM-DIM with a new fiber-linked fieldbus used in RIBF is contemplated in the future withpossible replacement of power-supplys themselves. Inthat case, it is likely that VME or CPCI controller willtake the place of CAMAC. It is not certain at thismoment whether EPICS will remain as RARF controlsystem or a new system will take over it.

3 THE FIRST PHASE
Fig. 1: Bird’s eye view of RIBF facilities.

2 UPGRADE OF LEGACY SYSTEM
2.1 Facility Descriptions
The existing facility (RARF) has been in operation
since 1986. In this heavy-ion (HI) accelerator complex,
there are a K540-MeV RIKEN ring cyclotron (RRC) andtwo types of injectors: a frequency-variable Wideröe linac(RILAC) and a K70-MeV AVF cyclotron. A energy
range of HI beam is from 0.6 MeV/nucleon to 135
MeV/nucleon and RI beam is produced by means ofprojectile-fragment separator (RIPS).

3.1 Main Concepts
The first phase in RIKEN-RIBF project is an additionof two cyclotrons (IRC and SRC) and experimental beamlines (Big RIPS). It is qualitatively no different fromRARF. However, it is not favorable now to use the same
proprietary field-bus and CAMAC as RARF employs interms of cost/performance efficiency, flexibility andscalability.
The followings are basic concepts for new control
system:• Vendor independent as much as possible• Use of object-oriented (OO) technology• Use of COTS as much as possible• Portable source codes• Software sharing with other labs
• Seamless integration with legacy systems• Reliable hardware regardless of cost disadvantage.
Most of the concepts above expect the last one is recent
trends in the industry. The last condition mainly comesfrom the peculiarity of Japanese government procurement
which disfavors software expenses.

3.2 Use of CORBA Middileware
One ofthe strong candidates satisfying above
conditions is a use of CORBA middleware for thecommunication layer. CORBA design priciples include:• Separation of interface and implementations• Heterogeneous distributed computing• Location transparency• Access transparency• Support of multiple inheritance of interface.
RPC, RMI and DCOM may not completely satisfy ourneeds for the moment.
However, current standard CORBA (Ver. 2.2) does notaddress some key complexities of distributed computing
for real-time embedded systems such as latency, fault
tolerance, causal ordering, deadlock and QoS. There havebeen some CORBA benchmarking reported [1~4], but
none in the context of embedded systems. We are going
to conduct preliminary testing of various ORBs
(VisiBroker, OmniBroker, etc.) and OS’s (VxWorks andpSOS for controller, Windows-NT, Linux and Solaris forclient) in the environment of accelerator control systemusing VME/CPCI as a field controller and some field-bus
including a fibre-linked remote I/O and GPIB. The OPIs
are most likely to be constructed by Tcl/Tk and Java. As
far as the database is concerned, it is deemed to be stillpremature to abondon RDBMS such as Oracle because of
its robustness and reliability. However, some trials ofOODBMS such as Objectivity/DB is already started inRIKEN. Figure 2 shows a schematic diagram of the testsystem.

Fig. 2: A schematic diagram of CORBA test system

4 MUSES CONTROL PROSPECTS
4.1 Timing Issues
MUSES controls involve qualitatively different aspects
from the first phase of the project that is essentially staticmachines. Its operation is inherently pulsed instead of DCfor cyclotrons. Varieties of particles and their momentum
require continuous tuning of timing signals. Therefore,
one has to be careful to identify the level of timing
requirement and accordingly choose the appropriate
source of hardware or software timing system.

4.2 Cooler Controls
There will be a set of an electron cooler and astochastic cooler for both ACR and DSR.
These
components directly affect the beam dynamics so that
their operations cannot be totally independent from thelattice magnet controls. Introduction of a fast feed-backsystem is considered necessary and it is currently being
investigated.

4.3 CORBA 3 and later
The next version of CORBA is supposed to address theproblem of current version for embedded systems in theform of quality of service specifications (MinimumCORBA , Real-time CORBA, etc.)[5] We expect thefuture version of CORBA will be more suitable to
MUSES controls.

REFERENCES[1] http://siesta.cs.wustl.edu/~schmidt/CORBA4.ps.gs[2] http://nenya.ms.mff.cuni.cz/thegroup/[3] http://www.kav.cas.cz/~buble/corba/comp/test/through/[4] http://www.horb.org/eval-team/acm98/dots.ps/[5] http://www.omg.org/news/pr98/9_9.html