The IHEP Accelerator

Utilities Control System

S. Goloborodko, A.Kholodnyi, E.Oustinov, A.Sytin
Institute for High Energy Physics , Protvino, Russia
Abstract
This paper presents the IHEP Accelerator Utility System ( AUS ) architecture and the hardware andsoftware organization of the Utility Control System ( UCS ). The size and complexity of UNK requires amulti-level multi-processor control architecture. Low level control for utility subsystems is performed bydistributed equipment controllers. The next high level of control is carried out by front end computers(FEC) spread around the main accelerator ring and Beam transfer line (BTL) and is interconnected withhigher level computers and operator consoles by a control network. A review of the general features isgiven.

Introduction
The IHEP Accelerator Utility System (AUS) includes safety equipment for personnel and machinery in
the premises of the accelerator complex. The Utility Control System (UCS) is composed of the following
sub-systems : electricity distribution network, gas analysis and compressed air, ventilation, fire-fighting anddrainage. It is made up of hardware and software designed to automate the control and so increase theeffectiveness of the accelerator operations staff and the utility control staff.
The UCS must transmit the necessary information to the dispatchers and to the operators of therespective services, as well as allow them to set, change or monitor utility systems parameters. It is also
necessary to ensure the correct order of the actions of systems and operators to guarantee the security ofpersonnel as well as the protection of the accelerator equipment. It is requisite to keep a record of AUS statechanges and UCS operators actions.
To perform these functions, UCS must provide for AUS data acquisition, AUS data processing andarchiving, the generation of control messages and transmission of these messages to the equipment of therespective control systems, the creation and update of the respective information databases, the presentationof the AUS state information to the operators, the generation of parameter-out-of limits warnings andprovide the possibility for manual remote control of the equipment and equipment diagnostics.

Organization of UCS Hardware.
A peculiarity of utility systems is the unusual diversity in the low-level data acquisition devices (pickups) and in the control devices in different sub-systems. Since the AUS sub-systems will be installed in all
operational buildings of the accelerator, a hierarchical structure is the obvious one for the UCS hardware (fig. 1 ).
The data acquisition and control hardware is built in Euromechanics (EM) crates with the MULTIBUS1(MB1) backplane bus and in an industrial-designed servo-amplifier equipment crate (EC). This configuration(one EM and one EC) provides support for 256 transducer inputs, 32 electrically operated valves and 8
actuator drivers for AC electric motors. All the motors for the compressors, pumps and valves usedthroughout the utility equipment are interfaced by Digital Servo Amplifier cards (DSA). A PC-16 modulewith an i8086 microprocessor is used as a crate controller in this configuration.
An analysis of input/output signal requirements for the various AUS subsections shows that they, as
well as the TPS connection, the generation of remote starting signals for the control devices in a given
building and the control message transmission may be effected using the following basic set of electronic
modules :- a multi-channel digital-input module with 96 input lines with opto-coupler isolation:
input signals: 24 V 10 mA.
- a multi-channel digital-output module with 16 output lines with opto-coupler isolation;
output signals: 5V, 400 mA;- a multi-channel analog-input module with 16 input lines with galvanic isolation:
input signals: +10 V with 5 mV precision;- a multi-channel analog-input module with 16 input lines with galvanic isolation;
input signals: 0-20 mA (this may be combined with the previous module);- a 2 to 4 channel IRPS interface module; this will enable the data to be exchanged with thehigher level controllers.
The EM data acquisition and control crates in one building are connected to a Utility Control Computer(UCC) using the MIL-1553 bus. The latter will provide the inter-linking of all sub-systems within abuilding and the transmission of the control messages to the sub-system controllers installed in the EMcrates. The UCC provides the communications through the network with the accelerator control computer,as well as with the central accelerator control console and local consoles in the operations buildings orutility consoles in the services buildings. The above requirements are satisfied within the conventionalarchitecture of accelerator control systems by a front-end computer (FEC) and one based on a Motorola
680xx microprocessor is used as the UCC .

Fig. 1.

Utility Control System.

A local console based on an IBM-PC computer is connected to the building LAN for start-up, tuning, repair
and equipment diagnostics purposes and may also be used as a local operator console for all sub-systems inthe building. In like manner, additional IBM-PC-based consoles, located in different buildings of theaccelerator complex, may be connected, provided they have a Control Network connection.
Obviously this architecture for the UCS presupposes that reliable independent sub-systems will beemployed for the low level equipment control of each sub-system of the AUS. These independent control
sub-systems must ensure the reliable operations of the AUS sub-systems even in case of malfunctions of
the equipment at higher levels of the UCS (EM & MB1 and UCC) and the data links (MIL-1553 andcomputer network). Hence, these independent sub-systems for low-level control must comply with thecurrent standards and must be attested accordingly.
In addition to the central accelerator control console, it is necessary to provide consoles for the UCS
services in the premises of the respective services. Utility consoles provide information, displaying the stateof the systems, while local consoles are mostly employed for test runs, diagnostics and repair.

The UCS software
The MTOS may be used as the operating system for the EM & MB crate controller (PC 16 module),
The remote terminal (RT) MIL-1553 bus driver, as well as a RS-232 serial port driver for possible later use,
are to be built into the MTOS kernel. Furthermore, utility and application-level protocols are to be
developed to download tasks from the higher-level computer (UCC), to the PC-16, to initiate or to suspend
the execution of the given tasks, to remove the tasks from the controller memory through the MIL-1553
bus and/or through a RS-232 serial port, as well as to ensure the interaction in the command-reply mode..
The FEC operates under LynxOS and uses the standard means of UCS equipment access, adopted for all theaccelerator control system, DEC workstations and ULTRIX are used for the accelerator control computersand consoles The appropriate choice of operating environment for the local console is MS Windows, as
this setting provides a uniform user interface for all applications. Since the development of applications
under MS Windows is quite laborious work, the use of commercial software development kits and libraries
seems to be the obvious solution to simplify the programming of applications and user interface. To
interact with the higher-level computer through the network, the PC/TCP Development Kit of theWindows Sockets library is to be used.
LabVIEW for Windows, capable of creating an almost complete set of applications based on an IBM
PC/AT, may be used for applications development. A set of VIs and servers which realize a protocol for
remote access from upper level computers and consoles to the ECs has been developed. This software
provides convenient tools for representation and access from LabVIEW applications to different accelerator
equipment. The icon-based graphical programming system LabVIEW provides a powerful environment forcontrol system design and gives significant gains in productivity with no sacrifice in performance andflexibility.
Such tools have already been used in the Beam Transfer Line (BLT) electricity control system and for
creating a prototype for the BTL utility systems.

Conclusion
The use of a hierarchical, networked architecture is suitable for this system. The distributed sub-systems
can be incrementally upgraded - or even replaced - with a minimum of impact to the rest of the system.
During the last accelerator run the BTL UCS was tested. The number of available menus on the local
control console have been increased progressively to cover all the required functionality and theirperformance has been improved using feedback from the operators. Most problems occur when the different
pieces of equipment are first connected to the network; mainly due to cabling faults. The main advantage
expected from using the UCS is the fact that is an OPEN SYSTEM available for many services and thedesign is based on the key elements: integration, distribution, easy of use, expandibility and reliability.

References
1. A.N.Alferov, B.L.Brook, A.F.Dunaitsev et al. "The UNK Control System", Proc. of the Inter. Conf. on
Accelerator and Large Exp. Ph. Control Systems, Springer, KEK Tsukuba, Japan
Nov. 11-15 1991,p 134.
2. Yu.I.Bardik, E.N.Kallistratov, A.A.Matushin et al., "Multidrop BUS Controller for IBM PC/AT",IHEP preprint, Protvino Russia, 1993, p 93-113.

3. J.Smolucha, A.Frank, K.Seino and S.Lackey "A New Architecture for Fermilab's Cryogenic Control
System". Proc. of the Inter. Conf. on Accelerator and Large Exp. Ph. Control Systems, Springer, KEK
Tsukuba, Japan, Nov. 11-15 1991, pp 96-100
4. C.Lemoine, M.Tyrrel "CAS and Alarm Console New Feature", SL/Note 93-102 ( CO ), November
1993. CERN.