THE CONTROL AND DATA ACQUISITION OF THE LHC TEST STRING
R.Saban, D.Brahy, J.Casas-Cubillos, M.Grippeling, D.Lavielle,
G.Leo, L.Madaro, A.Rijllart, M.Skiadelli
AT Division CERN, 1211 Geneva 23

I. INTRODUCTION
In 1994, CERN built and commissioned the first version of the LHC Test String [1]. It was composed of one
quadrupole and two 10-m long twin aperture dipole magnets. During the shutdown last summer, one extra
dipole magnet was added. As for the Accelerator Systems String Test [2] at SSC, the objective of the LHC
Test String is to study the phenomena which can be observed only when the components are assembled into
an LHC subsystem.
A. The organization of the runs
The first experimental run started in February 1995 and lasted until mid June. The first part of the run
included cryogenic system commissioning [3], sensor calibrations, and power system commissioning tovalidate the magnet protection system. The experimental programme that followed produced results leading toa modified machine design (number of quench relief valves), validated the quench detection and magnet
protection system [4] and left some questions unanswered (quench propagation). The String Team, which
consists of one specialist in each field (controls, cryogenics, data acquisition, powering, mechanics, survey
and vacuum) ensures the correct operation of the equipment for the duration of the experiment. It also makes
sure that the experiment yields the required data. The Experiment Committee approves experiments and sets
their priority. Both the String Team and the Experiment Committee report to the LHC Steering Committee on
Magnets and Cryogenics.
B. The Systems
The LHC Test String is supported by a number of systems. The vacuum system [5] includes a number ofgauges, pumps and gas analyzers. It maintains the insulation vacuum, which is essential for cryogenic
operation, to a few 10-6 mbar when the LHC Test String is cold and evacuates the beam pipes to around 10-9mbar.
The cryogenic system consists of a Cool-down and Warm-up Unit (CWU) and a String Feed Box (SFB) whichhandle the cryogenic fluids necessary for operating the LHC Test String. The main operational phases of thecryogenic system are:• cool-down from 300 to 80 K ,• warm-up to 300 K; both these actions use gaseous helium supplied by the CWU. The heliumtemperature is set according to a gradient across the LHC Test String,• cool-down to 4.5 K and magnet filling: supercritical helium is expanded inside the magnets until
the temperature reaches 4.5 K at the last magnet; at this moment the magnets are full with liquid
helium at 4.5 K,• cool-down to 1.8 K and normal operation: saturated superfluid liquid helium removes the heatfrom the pressurized helium inside the magnets via a longitudinal heat exchanger which runs
along the magnets,• recovery from a quench.
The powering system of the LHC Test String consists of a power converter with an internal current regulationloop, two switches that can open the circuit between the power converter and the LHC Test String and aquench detection system. The latter is designed to protect the magnets in case of quench.
Due to limited manpower, the utmost care has been taken to make use of standard industrial practice incontrols and hence to adapt the specification for a commercial offer. For the data acquisition, a technicalspecification was written and the system was purchased as a turn-key one from industry.

II. THE CONTROL SYSTEM
In line with the current trends at CERN [6,7], a control strategy similar to ones used in industry for
manufacturing and for continuos processes was adopted. Whenever possible in-house developments wereavoided. This resulted in a control system architecture based on industry standard Programmable Logic
Controllers (PLC) which are interfaced to the operators via an industrial network and a commercial
supervision software package running on a commercial computer platform.
Power
Converter

PC Compatible
RS232-C

Sinec H1/OSI
PLC

Dual monitor
Supervision
Workstation

X-Terminal
TCP/IP

PLC

A. The Process Control
Two very different approaches were adopted for implementing the process control of the LHC Test String.
Both are based on the same brand of commercial PLCs.
The first consisted of ordering the process control as an integral part of the turn-key cryogenic equipment: thetechnical specification [8] mentioned that the use of a certain brand of PLCs would be considered anadvantage and that the details of the communications between the PLCs and the supervision had to be agreed
between CERN and the supplier. This approach proved very efficient because while leaving the responsibility
for the performance of the equipment with the supplier, CERN could influence the choice of the control
hardware and software to take full advantage of installed infrastructures and in-house knowledge.
Additionally, since the PLC brand was a widely used commercial product, no extra burden was placed on the
supplier. This approach was used for example for the CWU.
The second approach consisted of using industrial process control hardware and software of the same brand as
the equipment mentioned earlier, but carrying out the integration, installation and programming in-house.
Despite insufficient man-power, this approach proved necessary in two instances: the LHC Test String
Cryogenic Feed Box control and the Vacuum monitoring. Particularly in the case of the former, the equipment
to be controlled was too prototypical to be described in a technical specification and frequent modifications
were needed for its evolution.
B. The Supervision
The supervision of the installation was implemented using a commercial industrial supervision package [9].
Monitoring the process was made possible via animated synoptics and trend curves; control was achieved by amouse click on the element to be controlled: a window specific to the element is displayed and the operator
enters the parameter values.
The process as a whole is surveyed by an alarm manager which receives the alarms from the field, informs theoperator by a beep and displays the alarms on a table where they can be viewed and acknowledged.
Additionally, the supervision package generates and keeps journal files which represent snapshots of systemparameters and alarms every minute.
On the PLC side, the supervision package gathers values of field parameters using the PLC manufacturer's
own protocol [10] over ethernet. Drivers for this protocol, which is based on the different ISO standards of the
OSI seven layer model, were purchased with the supervision package.
C. The Supervision of the Power Converter
The power converter was supplied with embedded controls based on VME. From the controls point of view, it
was an in-house development readily available that was already used in LEP and on other test installations
used for LHC superconducting magnet tests and R&D. The supervision in the latter case had already been
implemented using a commercial application enabler [11]. We adopted the same solution for the String. A PC
is linked via an RS232-C serial link to a module in the VME crate. The embedded software obeys a protocol
which allows the application to control, monitor and log the electrical current being supplied to thesuperconducting magnets of the LHC Test String.

III. THE DATA ACQUISITION SYSTEM
The specification of the data acquisition needs for the people responsible for the equipment and for theexperimenters was defined in a long series of meetings held over a period of more than one year. This allowed
the drawing-up of a technical specification for a common system [12].
A.The requirements
The users expressed needs on the one hand for an archiver which would continuously record all processparameters at 1 Hz and, on the other hand, for a transient recorder which would take snapshots of systemvariables during a quench at up to 1 kHz. This system had to be dimensioned for 500 inputs and had to allow
for a doubling of its capacity.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
Intermediate
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA
AAAA
StorageAcquisition Data
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA ofAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
Configuration
On-line
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA
AAAA
AAAA
AAA
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAcquisition
AAA
AAAA
and
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA
AAAA
Monitoring
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA
Data
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA
AAArchiver DataAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAA
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA
AAA
AAAAData
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAA
AAAAAAAAAAAAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
Process AAAA
Acquisition
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAA
AAA
AAAA
AAAA
AAAASystem
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
OracleAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAA
AAAA
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA
Database
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
AAAA
Transient Recorder
Data
AAAAAA
AA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
Configuration Data
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAAAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
Elementary
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
Data
Handling
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
Data Analysis
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAA
Scope
of
the
Supply
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Tenders for the project were requested from industry and the solution proposed by the lowest bidder was
accepted. A detailed calendar with milestones and written test procedures was prepared and agreed to by thecontracted supplier. The milestones included the acceptance of the functional analysis, tests at the works on a
reduced size system, tests at the works on a full sized system, commissioning and provisional acceptance tests.
Both the hardware and the software were to be supplied, together with the commissioning and a two year
guarantee.
B.The Architecture
The system is based on 3 VME crates each containing 18 8-channel 16-bit 1 kHz ADC modules, one CPU andone MXI-VME [13] interface. A dual monitor Unix® workstation running a LabView® application was
proposed to act as the man-machine interface for control and monitoring of the data acquisition system and asa configuration management tool. The three front-end CPUs record every input channel every millisecond anddeposit the values into a circular buffer.
C.Functionality
The archiver examines one value in one thousand in the circular buffer (i.e. one value per second) andcompares it with the previously recorded value; only if they differ by more than a predetermined value (ε) will
the newly read value be stored. For user comfort, the value for each input is automatically stored every ten
minutes.

For each input channel, the transient recorder can distinguish between three different recording intervals andoperates at two possible recording frequencies. In the pre-trigger interval and the first post-trigger interval the
input channel is usually sampled at the highest frequency. In the last post-trigger interval, sampling occurs at alower frequency: this is a consequence of the relatively longer time necessary for most signals to recover froma strong perturbation.
The recording strategies adopted for both the archiver and the transient recorder greatly contribute to reduce
the amount of data early in the acquisition process.
The application displays on two screens 12 stripchart recorders, each showing the behaviour of five systemvariables, in real-time or stored mode. The application allows the entry and edition of configuration
parameters for the archiver and transient recorder parameters, as well as the conversion type and coefficientsfor each input channel. Additionally, it exports the data into ASCII files which are inserted into the databaseat regular intervals.

IV. THE DATABASE
The database was largely inspired by the experience in LEP and SPS [14, 15] where operations data are
regularly stored in a database and are available to specialists for machine studies or diagnosis of unexpected
events. In the LHC Test String, data recorded by the acquisition system and stored in the supervision journal
files are inserted in the database at regular intervals, usually once per 24-hours around midnight.
The data transferred from the acquisition system comprise both raw and converted values from the archiver
and the transient recorder. Additionally, the configuration data which contain conversion information andsensor data are inserted in the database. With this and the raw data, it is possible to reconstruct the conversion
in case of doubt, or reconvert data from the raw values if a better calibration is subsequently produced. For thesupervision system, however, only the converted data in engineering units are transferred.

Process
Supervision
User
Data
Acquisition

Database

In order to reduce the table sizes and hence optimize extraction times, the data for each run are stored inseparate tables having the same structure. Each of these tables has five columns; the first two represent thedate and time respectively, the third is the identification of the channel and the last two are the raw and theconverted values. Since the data for any two channels is almost never recorded at the same instant (see section
on the functionality of the data acquisition system), only one set of two columns containing channel data is
attached to a time stamp.
Placing data of previous runs in different tables allows us to partially back-up the database on disk, since thesetables can be backed up on tape once the run has finished.
The transient data is placed in one table that has 5 columns. The first corresponds to the event that triggered
the data acquisition, the second to the number of milliseconds after or before this event. The last 3 columns
are identical to the last 3 columns of the archiver tables.
Once the data is in the database, it is available on every desktop at CERN either by using a desktop
application on a PC or through a World Wide Web page [16].

V. COST
The supervision application for the CWU, the SFB and the Vacuum of the LHC Test String has cost 15
man•months and 35 k CHF for both the hardware and the software. The process control for the vacuum andthe PLC communications for the whole project is evaluated at four man•months. The SFB process control is acontinuing operation since the many structural modifications of the LHC Test String generate modifications in
the process control: it can, however, be evaluated at 12 man•months.
The cost of the data acquisition system is better known: it amounts to 270 kCHF after the system upgrade
following RUN1.
The database system was constructed as an upgrade of an existing installation and the cost of hardware was 60
kCHF, while 15 man•months have so far been invested for the design, implementation, commissioning andrunning of the database and associated data extraction tools.

VI. PERFORMANCE
The performance figures are given for RUN1, which started on February 22 1995 and ended on June 12. Many
improvements to the different systems have been made during the shutdown following RUN1, but no longterm experience is yet available to assess their effectiveness.
On one occasion only during RUN1 the supervision system was down for two hours as a result of an error ofmanipulation. One programmed stop per week to install requested upgrades was negotiated with the users
during the run. However, during the commissioning a continuous assistance was provided by the supervisionand process control teams. The process control PLCs exhibited malfunctioning only during the initial tests
preceding commissioning; the PLCs were stable during the run and did not visibly contribute to down-time of
the LHC Test String. 850 datapoints are read from the field every 10 seconds, 255 data points are archived
every minutes yielding, 250 Mbytes of data for RUN1.
The archiver part of the data acquisition system was continuously running throughout the run, except for aweekend when it was inadvertently stopped. Additionally, as for the supervision system, programmed stops
were negotiated to install requested system upgrades or bug fixes. This amounted to 5% of the run time.
The transient recorder missed only one trigger over 48 due a wrong configuration file loaded by mistake by anoperator.
The database design started very late in September 1994; at the beginning of RUN1 in February 1995 a firstversion was ready to accept data. No time was available for prototyping and tests with large amounts of data.
The data insertion programs interpreting files exported from the data acquisition system were graduallycommissioned. After several trials with Oracle® products for data presentation, it was decided to write an
Excel® application to extract the data and chart it. The performance, although initially acceptable, started to
decline as data increased the sizes of the tables. A consultant was asked to examine the performance of thesystem and he came up with a number of recommendations which were duly implemented. Typical extraction
times obtained today are just above one minute for three signals recorded during one week and averaged every
10 minutes. 6.5 Gbytes of data were inserted in the database during RUN1.

VII. CONCLUSION
The control and supervision systems were the ones we were most familiar with. We benefited from experience
gained on similar installations with a comparable amount of PLCs and field parameters. The process for theString Feed Box was by far the most complex with 24 control loops which switch reference variables
depending on the operational phase. Despite some initial difficulties with the communications, the supervision
benefited from a mature product and has performed reliably since the beginning of RUN1.
The data acquisition system has performed as specified: reliable, in-time and user-friendly. It has been our
first experience with turn-key systems specified for, and built by, industry. The project has benefited from amature technology both for the hardware and the software; ready-made available software components havegreatly contributed to the success and low-cost of the project.
The performance of the database was by far the most difficult to achieve and maintain at the level required by
the users. Although the problems of such a database were known because of experience with LEP, additional
problems were encountered in fields such as transfer of data to the database and extraction times of data. The
volume of the database started to increase very rapidly at the beginning of the run; after one and a half monthsof operation the average number of points recorded per unit interval was halved by carefully tuning thearchiver. This was achieved by adjusting the value of ε for each channel recorded by the archiver which had
been set too low.

VIII. ACKNOWLEDGEMENTS
The authors would like to thank the LHC Test String Project Leader, P. Faugeras for his continued support
and the confidence he put in them. Because the data acquisition project took the form of a collaboration rather
than a commercial deal, the authors would like to acknowledge G. Endendijk and D. Motshagen from INCAA
Computers, Apeldoorn, Holland. We would also like to thank our colleagues in the SL and CN Divisions of
CERN, S. Santiago, C. Delamare, R. Billan, N. Segura-Chinchilla and I. Reguero for their advice and help on
issues related to database design, commissioning and daily operation. Last but not least, our thanks go to theString Team and other users, who by their light-hearted and natural approach to our systems have shown us
what they were there for.

IX. REFERENCES[1]

P.Faugeras, Assembly and Commissioning of the LHC Test String, Particle Accelerator Conference
PAC95 Dallas, 1-5 May 1995

[2]

P.Kraushaar, The Accelerator Systems String Test Program, SSCL Pre-print 333, May 1993

[3]

A.Bézaguet, J.Casas-Cubillos, B.Flemsaeter, B.Gaillard-Grenadier, T.Goiffon, H.Guinaudeau,
P.Lebrun, M.Marquet, L.Serio, A.Suraci, L.Tavian, R. van Weelderen, The Superfluid Helium
Cryogenic System for the LHC Test String: Design, Construction and First Operation, Cryogenics
Engineering Conference, Columbus, Ohio, 17-21 July 1995

[4]

F.Rodriguez-Mateos, L.Coull, K.Dahlerup-Petersen, D.Hagedorn, G.Krainz, A.McInturff, A.Rijllart,
Electrical Performance of an LHC Test String of Magnets Representing a half-cell of the LHC
Machine, Magnet Technology Conference, 11-16 June 1995, Tampere, Finland.

[5]B.Angerth, F.Bertinelli, J-C.Brunet, R.Calder, F.Caspers, P.Cruikshank, J-M.Dalin, O.Gröbner,
N.Kos, A.Mathewson, A.Poncet, C.Reymermier, F.Ruggiero, T.Scholz, S.Sgobba, E.Wallen, The
Large Hadron Collider Vacuum System, Particle Accelerator Conference PAC95 Dallas, 1-5 May
1995

[6]

R.Saban, Integrating Industrial and Accelerator Control Systems, Particle Accelerator Conference
PAC95 Dallas, 1-5 May 1995

[7]

M.Rabany, A Proposal to Move from the LEP Topologial to an LHC Funtional Control System
Architecture, this conference.

[8]

Technical Specification for the Delivery and Installation of Cooldown and Warm-up Units forSuperconducting Magnets, IT-1987/LHC/AT, October 1991.

[9]

USData®, Factory Link® Fundamentals, Version 4.4, 1995

[10]

Siemens, Communication Processor CP143, Users Manual Volume 1 and Volume 2, 1993[11]

National Instruments, LabView® User Manual, September 1994

[12]

Specification for a Data Acquisition System for the LHC Test String, CERN/AT-Group Note 94-02[13]

National Instruments, Instrumentation Reference and Catalogue, Test and Measurement, Process
Monitoring and Control, Section 4 on VXIbus and MXIbus Products, 1995

[14|

R.Billen, F.Bordry, C.Delamare, E.Hatiangeli, F.Roeber, LEP Accelerator Logging System Using
On-Line Database, ICALPECS93, Berlin, November 1993.

[15]

R.Billen, E. Hatziangeli, I.Laugier, I.Reguero, N.Segura, Mission Critical Database for SPS
Accelerator Measurements, this conference[16]

F.Momal, Using World Wide Web for Control Systems, this conference