Integration Feasibility of the Existing Linac Control Systemand Ring EPICS System at KEKB
Kazuro Furukawa∗, Norihiko Kamikubota, Kazuo Nakahara, Isamu Abe and Akihiro Shirakawa
National Laboratory for High Energy Physics (KEK)
Oho 1 – 1, Tsukuba, Ibaraki 305, Japan
Abstract
In the KEKB project both the ring and the linac accelerators are to be upgraded from the TRISTAN project. It wasrecently decided to employ EPICS control software for the KEKB ring controls. It is reasonable to use such maturecollaboration-based software when starting to build a new control system. However, on the linac side, which will beupgraded from 2.5 GeV to 8 GeV, we have been operating a new separate control system, employing international andde-facto standards with an object-oriented design for the last two years.
We are thus searching for a scheme to join these two control systems together, since it is important to have a tightcontrol coordination between the linac and ring in order to achieve a higher luminosity in physics experiments. In thisreport, several schemes for the integration between the ring and the linac are discussed.

I. Introduction
Modification of the KEK electron/positron linac for the B-Physics (KEKB) project with an improved beam current
and energy started in 1994 [1]. We will upgrade our linac energy from 2.5 GeV to 8 GeV by 1998. A control system isalso being prepared for it employing international and de-facto standard systems with object-oriented design [2]. It will
improve both functionality and reliability [3].
In the project the linac should provide beams of better quality, stability and availability in order to achieve a higher
luminosity in the ring. Thus, cooperation is indispensable between the control systems at the KEKB ring and linac.
Extensive studies must be carried out in order to understand the correlation between the operational parameters in bothaccelerators with common database and accelerator-analysis codes.
Recently it was decided to employ EPICS (Experimental Physics and Industrial Control System) [4], for the KEKB
ring controls and the control software is being reconstructed while maintaining most of hardware resources from theTRISTAN project.
On the other hand, we have been gradually rejuvenating the linac system since we must continue beam injection tothe Photon Factory (PF) ring during the improvement. It is reasonable to employ EPICS as a result of the international
software-sharing effort when a new control system is designed. However, the issue of integration with the existing linac
control system remains.
In the former TRISTAN project, accelerator operation was performed separately at the linac and ring control rooms.
Although some control information could be exchanged concerning the last part of the linac, it was not much used during
normal operation. In the KEKB project, it is necessary to merge at least the beam handling console.
It is very desirable to have a common control architecture. Fortunately, we use a similar hardware architecture in bothof the new control systems. There should be possible a scheme to shift over toward common EPICS controls.
In this paper we consider the technical aspects of the integration feasibility of the existing linac system and the ring
EPICS system. Operational aspects will be considered elsewhere.

II. Control System Cooperation Between the Linac and Ring
In order to achieve system cooperation between the KEKB linac and ring, the operational procedure and use of thecontrol-room are under discussion. From a technical point of view, there are several possibilities. The use of EPICS atthe linac is of course one of them. Below we describe four major possibilities.
A. Employment of EPICS at Linac
In order to integrate two control systems the best solution would be to use EPICS at the linac control system replacing
the existing one, since common resources could be shared between the two control systems without much effort. This
scheme would be taken if both control systems were to be designed again.
∗ Also at CERN/PS during 1994. furukawa@kek.jp.

However, because of the need for PF ring injection we cannot shut down the linac accelerator for a long period during
the KEKB upgrade and much of our manpower will be necessary to follow a gradual accelerator improvement program.
It is thus quite difficult to replace software during this period.
Although the equipment access method over the network was standardized at the linac, we have used three different
methods for the graphical operator interface: MS-Windows GUI applications, DOS-based touch panel systems and Tk[5] based X-Window GUI applications. Because of such a variety it would take some time to re-design the graphicaloperator interface under EPICS.
Also, the equipment-control software based on object-oriented design at the linac does not match the channel-oriented
EPICS software, so it would be necessary to redesign the structure of most application software for controlling the linac.
In order to accomodate the differences between equipment access methods it is possible to develop special EPICS
records, such as magnets and klystrons. Although we may emulate our current access method on EPICS IOC (Input
Output Controller), those pieces of software would become large, and we would have to modify not only the client
applications, but also the EPICS source tree.
If we change to an EPICS environment, it would be attractive to implement such records to fulfill the equipmentoriented design at the IOC level. However, during the construction time, such a complication should be avoided and amore simple scheme should be implemented.
B. EPICS Capability in the Current Linac Control System
The current linac-control system comprises VME front-end systems, Unix systems and operator interface subsystems.
If it would be possible to implement the EPICS IOC capability into the current VME systems, both the current linac
software and EPICS client software could be executed and a gradual transition to EPICS could be accomplished.
One of the authors (k.f) studied such a feasibility [7]. As a result, the idea came up that if we could emulate some
VxWorks system calls, which EPICS IOC utilizes, in a thread environment, we should be able to execute EPICS IOC
codes, although dynamic symbol manipulation is technically not easy to implement.
On the linac VME, while the OS9 operating system is currently employed, most software is written for both the OS9and LynxOS operating systems. We had a plan to move to LynxOS, which is currently suspended. With LynxOS wecould use the POSIX thread (pthread) environment, which is one of the standard thread specifications. Though the code
is not yet finished, an implementation has been attempted on LynxOS.
Therefore, such transition is possible. However the software development required is too much compared to theamount of sharable resources. Since the transition from OS9 to LynxOS has been suspended for certain reasons, thisscheme is not feasible now.
It would be interesting to adopt the POSIX real-time standards to the EPICS IOC, since it would expand the EPICS
application area. It should be discussed not only for KEKB integration, but also for more general areas.
C. Communication Protocol Conversion
In the linac control system we implemented our own control protocols both between Unix and VME and between
Unix and the operator interfaces. On the other hand, in EPICS the Channel Access protocol is used between the IOCand OPI. If we could convert one of these protocols into the other, the two control systems could communicate with eachother.
A server for EPICS Channel Access, called Portable CA server [8], is being developed in the EPICS collaboration,in order to enable access to external controls from EPICS Channel Access clients. Since several sites use it without any
obvious problems, the Portable CA server could be installed at the linac in order to allow EPICS clients to reach the linaccontrols.
After writing protocol conversion routines for the linac equipment, EPICS Channel Access clients could see the linac
accelerator as one large IOC. Although it is asymmetric as shown in Figure 1 and we could not share low-level controls
between the linac and ring, such a solution would be very simple to implement.
In such a scheme, if it is necessary to reach an IOC in the ring side, from the linac, Channel Access library routines
could be called from inside the linac operator interface. At least at the beginning, some kind of security checking should
be made between the linac and ring controls.
D. Common Upper Level Control Protocol
A Channel Access server described in the previous section is a practical solution in a one-to-one conversion. However,
we must soon think about the Photon Factory ring as one of the downstream clients for the linac. Also, controls for physics
experimental groups and other facilities may be loosely combined.
In such a multi-architecture situation it is natural to design a common upper-level protocol and several groups areworking to implement it. The CICERO project is a development collaboration based on CORBA (Common Object

EPICS CA Clients

Linac Console

Channel Access Protocol
CA server

Ring
IOC's

LinacControls

Figure. 1. CA server implementation at Linac to enable common applications.
Request Broker Architecture). In the EPICS collaboration cdev (control device) [9] is proposed as the common API andimplementation is made available.
Since cdev is designed to be object-oriented, it should be easy to write an interface to the linac control protocol.
Although the link at the top level with cdev is not efficient in speed, software design will be clear.
Although cdev over the distributed network is not yet defined well, we expect that ACE (Adaptive CommunicationEnvironment) or CORBA will be soon applied to cdev. Figure 2 shows such a common environment.
Common Applications
cdev

ACE or CORBA

cdev

cdevcdevcdev

LinacRing

PF Ring

OtherFacilities

Figure. 2. Possible integration of control systems at KEKB with cdev and ACE or CORBA. Common Applications may
communicate with any control system.
Although this scheme seems very suitable, and would provide a common application environment, the number ofexisting general application programs is small. Most of EPICS clients use only the CA protocol, but we hope that more
application programs will be developed on cdev. In the long run this scheme is considered to be the most promising.

III. Other Services
Other services, such as computer resources, computer networks and relational databases, as well as their management,
can be combined more easily than the control protocols. Since our manpower is very limited, we should pay attention tomerge such services.

IV. Conclusions
The above discussion shows two schemes which are feasible for merging the existing linac control system and theEPICS ring control system. One is to employ the CA server at the top of linac controls for a short-term solution.
The other is to implement a cdev environment over the top of the two control systems as a long-range plan. We need todesign a network-communication interface and a set of common control application programs in the EPICS collaboration.
If the adoption of cdev is successful, we may skip the use of EPICS on the linac side. Of course, in order to save
manpower, we may design new sub-systems with EPICS. We would not have any problems with such a mixture ofarchitectures, since cdev can manipulate all communication between them.
As a result of these considerations we hope to achieve successful results with the KEKB project.

V. Acknowledgment
One of the authors (K.F.) is deeply grateful to Dr. B. Kuiper for supporting this work during his stay at CERN, andto Mr. R. Dalesio for his EPICS support via Internet. The authors would like to thank the linac staff and control-groupmembers of the KEKB ring for valuable discussions.

References[1] A. Enomoto et al., “Re-formation of the PF 2.5 GeV Linac to 8 GeV”, proceedings of the 1994 International Linac
Conference, Tsukuba, Japan, 1994, p. 184.
[2] K. Furukawa et al., “Upgrade Plan for the Control System of the KEK e+ e− Linac”, Proceedings of the International
Conference on Accelerator and Large Experimental Physics Control Systems, Tsukuba, Japan, 1991, p. 89.
[3] N. Kamikubota et al., “Improvements to Realize Higher Reliability on the KEK Linac Control System”, theseproceedings.
[4] Leo R. Dalesio et al., “The experimental physics and industrial control system architecture: past, present, andfuture”, Nucl. Instr. and Meth. A 352, 1994, p.179.
[5] K. Furukawa et al., “Control System for a Bunch/Profile Monitor at the KEK e+ e− Linac”, Proceedings of the 1994
International Linac Conference, Tsukuba, Japan, 1994, p. 819.
[6] T. Katoh et al., “Proposed Control Systems for the KEKB Rings”, these proceedings.
[7] Feasibility study of EPICS on LynxOS was done by K. Furukawa at CERN/PS.
[8] J. Hill, “Portable CA server”, private communication.
[9] J. Chen et al., “An Object-Oriented Class Library for Developing Device Control Application”, these Proceedings.
C. Watson et al., “Introduction to Cdev”, 1995.