Generalized Control And Data Access
At The LANSCE Accelerator Complex -Gateways and Migrators*
S. C. SCHALLER and M. A. OOTHOUDT
Los Alamos National Laboratory
Los Alamos, New Mexico 87545, USA
All large accelerator control systems eventually outlast the technologies withwhich they were built. This has happened several times during the lifetime of
the accelerators at Los Alamos in the LAMPF/PSR beam delivery complex.
Most recently, the EPICS control system has been integrated with the existing
LAMPF and PSR control systems. In this paper, we discuss the provisions thatwere made to provide uniform and nearly transparent sharing of data among thethree control systems. The data sharing mechanisms have now been in use
during a very successful beam production period. We comment on the successes
and failures of the project and indicate the control system properties that makesuch sharing possible.

1. INTRODUCTION
The Los Alamos Neutron Science Center (LANSCE) at Los Alamos National Laboratory is composed of an 800MeV proton linac, a Proton Storage Ring (PSR) to compress the beam pulses in time and beam lines that transport
the proton beams to experimental areas including some with targets devoted to neutron production. The original
LAMPF Control System (LCS) controlled the linac and several external beam lines [1]. About 10 years ago aseparate control system was constructed to handle the storage ring [2]. In the past few years, server software has
been added to allow LCS access to PSR data and commands [3]. This past year we have embarked on a project toupgrade the PSR controls to an EPICS-based system [4]. The combined new control system is called the LANSCE
Control System (also LCS). This paper discusses the data and command access infrastructure needed to keep aheterogeneous control system functioning smoothly and with high reliability in the face of the major upheavals
caused by such an upgrade. A complete description of the status of the PSR controls upgrade can be found in acompanion paper at this conference[5] .

2. THE ENVIRONMENT OF THE UPGRADE
The basic goal of the PSR controls upgrade was to introduce more reliable and flexible hardware and software while
continuing to provide a highly reliable and available controls environment for accelerator operations anddevelopment. Budgetary constraints forced us to use an incremental approach to the upgrade. This condition meantthat many parts of the old system would have to work with the new system for periods of unknown duration. The
need for high reliability implied that we needed fallback capabilities in case some parts of the upgrade encounteredproblems that severely interfered with operations. A constraint that aided us in making control system decisions was
the long term goal of using EPICS-based controls for the entire LANSCE control system.
Fig. 1 provides an overall view of the data access environment with the three (LCS, PSR, and EPICS) controls
systems in place. The upgrade plan had essentially two parts: 1) replace the PSR front-end computers ( called
Instrumentation SubSystems or ISSes) with EPICS Input/Output Controllers (IOCs) and 2) move the PSR
application programs onto the EPICS Operator Interface computers (OPIs). We expected that not all the PSR frontend computers could be replaced at once and also that if problems should develop with the EPICS IOCs, we shouldbe able to go back to one or more of the original PSR front-end computers. We did, however, expect that once the
PSR application programs had been moved to the OPIs we would not have to fall back to the original PSR operator
interface.
* Work supported by the U.S. Department of Energy.

LinacControls

EPICS
Controls

Old PSR
Controls

EPICS
OPI
Epics to LCS
Gateway

LCS
Data

LCS
Application

EPICS
IOC

EPICS to PSR
Gateway

PSR
ISS

PSR/EPICS
Migrator

PSR
Database

LCS to PSR
Gateway

PSR
Application

Fig. 1. Data flow in the LANSCE control system. Commands flow in reverse.
2.1 Data availability
The data access environment in the various control systems differs as follows:o LCS data is acquired on demand through VAX/VMS and VAXELN systems. The data itself comes from the
hardware through CAMAC, RS-232 and locally designed hardware interfaces. All references to LCS data make useof the static LCS database.
o PSR data in the old PSR control system was obtained from the dynamic central PSR control system database.
The data was continuously acquired through CAMAC on PDP-11-based ISSes. The central PSR database was
updated at regular intervals from information contained in the ISSes.
o EPICS data is extracted on-demand or on-change from dynamic databases residing in the EPICS IOCs. The IOCs
obtain data by polling through CAMAC interfaces, which are the same CAMAC interfaces that were on the ISSs.
Access to the databases in the IOCs is via EPICS Channel Access, a TCP/IP-based protocol.
2.2 Application program execution
The environments for application programs and generic tools also vary among the three control systems.
o LCS applications/tools run on VAX/VMS systems. Communication with the data access systems is via a
locally designed RPC interface based on DECnet.
o Old PSR applications run on a single VAX/VMS system. They acquire data from the local central PSR database.
Some PSR applications, however, access the CAMAC directly without going through the database.
o EPICS applications/tools run on EPICS OPIs which in our situation are Sun workstations. The applications
communicate with the IOCs via EPICS Channel Access.

3. COMMUNICATION PATHWAYS
The data and control pathways needed to support the upgrade were determined by the following requirements.
(i) We wished to continue using a number of generic LCS tools to communicate both with PSR and EPICS
channels. In particular, we wanted to make use of the LCS data archiver and LCS knobs. This meant that we neededa path between LCS applications and both PSR and EPICS channels.
(ii) Since we didn’t know how many of the old PSR ISS systems would be converted to IOCs and because weneeded a mechanism to fall back from IOCs to ISSes, a path was required from the EPICS OPIs to the central PSR
database. Note that this requirement restricted our freedom in naming channels in the IOC databases.
(iii) The long range desire to have the entire LANSCE facility controlled through EPICS and the fact that somePSR data physically resides on LCS systems meant that we needed to provide LCS data to EPICS OPIs.
(iv) Finally, we knew that not all PSR applications would be converted to EPICS OPI programs. The unconverted
PSR applications would need to continue to acquire their data through the central PSR database, including data that
had been moved to the EPICS IOCs.
3.1 Gateways
The requirement in (i) above for giving the LCS system access to PSR data and commands was already in place
before the current upgrade began. As part of an earlier project to combine the linac and storage ring controls in asingle control room and to move toward a single operator interface for the two machines we had implemented aserver process on the PSR control system. This server responds to generic data and command requests from LCS
application programs and tools. This server is labeled “LCS to PSR Gateway” on Fig. 1. It implements the LCS
standard pseudo-device access protocol and allows tools such as the LCS archiver and knobs to have access to PSRdata and commands.
We defer the second part of requirement (i), the LCS access to EPICS, until after we have discussed migrators below.
Requirements (ii) and (iii) essentially required us to provide the EPICS channel access protocol on both the LCS andPSR systems. Fortunately, a similar requirement had arisen at DESY and, through the EPICS collaboration, we
became aware of preliminary work on an EPICS to DESY gateway that ran on VAX/VMS systems. Mathias
Claussen and Gabor Csuka kindly shared their code with us and we used it to develop the software that forms the“EPICS to LCS Gateway” and the “EPICS to PSR Gateway” on Fig. 1. As part of this development, we added
channel access puts and monitors to the DESY gateway and modified the LCS database to more closely conform to
the EPICS database functionality.
3.2 Migrators
The need to run unconverted PSR applications in requirement (iv) meant that the PSR database had to contain current
data and allow commands to channels without regard to whether these channels were on an EPICS IOC or on an
original PSR ISS system. The original PSR database update scheme used a program called the “migrator” to readthe ISS databases and put the new data in the central PSR database and to send changed command parameters fromthe PSR database to the ISSes where the commands would take effect. This migrator effectively kept the PSR andISS databases synchronized.
Requirement (iv) meant that we had to find a way to keep the PSR and IOC databases synchronized. To do this we
implemented another migrator, the “PSR/EPICS Migrator” in Fig. 1. This migrator runs in the context of the old
PSR control system and uses the notification on change mechanisms that are present in both the old PSR system
and in the EPICS IOCs.
Unlike a gateway, a migrator has a fixed list of channels and channel fields to handle and it provides databidirectionally. The PSR/EPICS migrator handled three types of data. Alarm and warning limit changes made by
LCS or PSR tools in the PSR database were polled and sent to the EPICS IOCs when needed. Commands given
by LCS or PSR tools were migrated from the PSR database to the EPICS IOCs. The PSR database provided
notification on change for these channels. Commands, readbacks and alarm/warning limit changes made by EPICS

software were migrated from the IOC databases to the PSR database. For these channels, EPICS channel accessmonitors rather than polling could be used.
Note that with the migrator and LCS to PSR gateways in place, we have effectively satisfied the second part ofrequirement (i), namely providing LCS access to EPICS data. LCS tools and application programs can request
EPICS IOC data by going through the path as follows: LCS application -> LCS to PSR gateway -> PSR database-> PSR/EPICS Migrator -> IOC. The data is returned along the same path. This route is admittedly roundabout, but
its existence allowed us to concentrate on other aspects of the upgrade and helped us to meet our schedules.

4. LESSONS LEARNEDThe process of creating gateways and migrators has given us a wider perspective on the issues of control systemdesign and the underlying philosophies. Compromises in performance and functionality are inevitable in making
such disparate systems communicate. We hope that some of our experiences may be of use especially in light of thecontinuing discussions on software sharing [7] that have been and are part of the ICALEPCS conferences.
One of the difficulties in integrating these three control systems was differences in their basic data acquisition
philosophies. LCS being the older system was designed with a static database and entirely demand-based dataacquisition. Both PSR and EPICS have live databases. The EPICS databases are located in the IOCs; the PSR
databases are located in the ISSes and also replicated in the central PSR database. To supply the EPICS
notification-on-change functionality, we had to implement a polling mechanism in the LCS system. The polling isdone at a fairly high level and hence has less than optimal performance. Parts of the LCS system already support
polling at a low level; we expect to use these in the next version of the EPICS to LCS gateway.
Especially during the EPICS control system commissioning and also during the initial storage ring turn-on this year
we had a very fluid controls environment. Sometimes devices were available on IOCs and sometimes on ISSes;
frequently we ran with a combination of IOCs and ISSes. We were forced to adopt a mechanism for global
configuration control which kept lists of channel names that were used by the gateways and migrators to determine
which channels to handle (or not to handle). Through all of this OPI screens were being built which referenced
channels without regard to their location, i.e., whether they were on an IOC or ISS. In addition, generic LCS tools
were in constant use to observe the same channels.
Error handling differences among the three systems also created some problems. Detailed error messages when dataacquisition problems occurred were the norm in both the LCS and PSR systems. The VAX/VMS condition codemechanism was used to report error conditions. This mechanism allowed detailed errors to propagate to higher levelsof code rather readily. EPICS errors are reported by a small set of status and severity codes and usually cause data
displayed on the OPIs to change color. This usually meant that operators knew that the data was good or bad but not
why it was bad. We added a number of diagnostic screens to the EPICS OPIs to allow access to more detailed error
information.
Another feature that caused problems for the gateway and migrator software was the differences in database contents
and functionality among the three control systems. Generic control system tools acquiring data and issuingcommands through a gateway need complete information on the channels they are handling. In several instances,
our gateway functionality was compromised either because the databases did not contain sufficient information or theinterface was not sufficiently robust. In evaluating the functionality offered by each of the three systems, thefollowing observations have been made:o Multiple-state channels (i.e., mux positions, magnet states) should be straightforward generalizations of simple
binary channels. In fact, binary channels should be a specialization of multiple-state channels. All possible channel
states should be spelled out in the database -- either explicitly listed or algorithmically generated. Problems arose in
the EPICS to PSR gateway and in the LCS to PSR gateway because some states needed by generic EPICS and LCS
tools were not in the PSR database.
o It is important to distinguish between two types of analog channels, namely, setpoint channels (e.g., DACs) andincremental channels (e.g., stepper motors). It may be possible to treat an incremental channel as a setpoint
channel by referencing an associated data channel, but, especially for knob-based control the knowledge of theincremental property is very useful. In an environment that has both setpoint and incremental analog channels both
setpoint and incremental commands should be supported.

o In a similar vein, multistate channels should support a “next state” command -- essentially a generalization of abinary toggle command. Needless to say a “go to this state” command, i.e., a setpoint command, is also needed.
For a robust implementation, these commands require information about the possible states of the channel from thedatabase.
o Access to complete channel information is vital to building robust generic diagnostics. In particular, it should bepossible to determine hardware addresses through references to the database. The EPICS channel access protocol
explicitly disallows such access.
o The channel naming standards must be general enough so that the name space can be common for many
subsystems. Although the mapping had irregularities that had to be ironed out, the LCS/PSR integration was
greatly aided by the fact that their channels shared common naming conventions. These conventions weremaintained for the most part when the EPICS IOC databases were defined.
o One would not expect analog data formats to be common among such varied systems. EPICS channel access,however, defined a “network” standard format. The LCS and the old PSR systems use VAX floating point but the
EPICS system uses IEEE floating point. Provisions were made in the server (i.e., gateway and migrator) software
to do the necessary format conversions.
o Some database functions, including alarm and warning limits were found to be provided in different ways. Somesystems handled only one kind of limit, some gave upper and lower limits and some gave target values plus
tolerances. A generic system should include algorithms to translate sensibly among these options. The
EPICS/PSR migrators in particular were faced with making some difficult and sometimes arbitrary decisions.
o Data representation also entered in the assumptions some systems made about accessibility to “raw” data. LCS
data originally came from a limited set of I/O channels which all had a well-defined raw data representation. The raw
data was used extensively in the LCS system in particular to provide diagnostic information. The lack of welldefined raw data in the PSR and EPICS systems required some approximations to be made when raw data requests
were made by LCS tools.
The compromises that had to be made in each of these areas have a significant effect on the performance,
functionality and maintainability of the combined system. The fallback requirement also limited the freedom wewould liked to have had in EPICS database structure and naming. But perhaps the real frustration came from having
to solve once more problems that one has already solved before.

5. FOR THE FUTURE
The combination of gateways and migrators described here served to glue together the LCS, PSR, and EPICS
systems for a successful production run. Our primary goal for this year was to eliminate the PSR ISS computers.
We have successfully done that -- and thus the the PSR ISS box in Figure 1 could be grayed out. In the near future,
we hope to eliminate the entire right hand side of Fig. 1 by replacing the PSR functionality with EPICS-based
systems. One thing this change will require is direct access to EPICS IOC data by LCS application programs. This
project is already under way.

One of the recent advances in the EPICS collaboration has been the implementation of a server-level application
program interface [6]. This interface supplies a standard mechanism to connect the EPICS channel access protocol to
non-EPICS control systems. This software will allow us to do away with the rather ad hoc channel access interface
used in our current EPICS gateways. Being part of the standard EPICS software release, this interface will allow us
to take advantage of new EPICS developments.

ACKNOWLEDGMENTS
Matthias Clausen and Gabor Csuka of DESY generously shared their initial developments of an EPICS gateway.
Jeff Hill of the EPICS development team at LANL helped to guide us through the mysteries of the EPICS channel
access server. Eric Bjorklund, John Faucett, and Gary Carr, our colleagues on the LANSCE controls team, provided
many useful comments.

REFERENCES[1] G.P. Carr et al., Proceedings of the 1987 Europhysics Conference on Control Systems for Experimental
Physics, CERN Yellow Report 90-08 (1990) 107.
[2] P.N. Clout et al., Proceedings of the Second International Workshop on Accelerator Control Systems, Nucl.
Instrum. Methods. A247, (1986) 116.
[3] S.C. Schaller et al., Proceedings of the 1991 International Conference on Accelerator and Large Experimental
Physics Control System, KEK Proceedings 92-15 (1992) 7.
[4] L.R. Dalesio, et al., Accelerator and Large Experimental Physics Control Systems,, Nucl. Instrum. Methods.
A352, (1994) 179.
[5] M.A. Oothoudt et al., these proceedings.
[6] J.O. Hill, these proceedings.
[7] B. Kuiper, Accelerator and Large Experimental Physics Control Systems,, Nucl. Instrum. Methods. A352,(1994) 501.