Database Requirements for the Vacuum Systems of LHC
M. Steffensen and P. M. Strubin
CERN, Geneva, Switzerland

Abstract
The new Large Hadron Collider (LHC) which will be built over the next decade at CERN requires two
independent vacuum systems. One will be a high vacuum for the two 26 km long beam pipes and the other is needed
for the insulation vacuum in the cryostat and helium distribution system for the superconducting magnets. Several
thousands of components will be acquired, assembled and installed in the ring tunnel. All active components will
eventually be remotely controlled. Several phases can be identified during the project lifetime, starting from thepreliminary design and ending with exploitation. Each phase requires different sets of data to be available. Thispaper identifies the required data, when this data should be available, the needs for integration with other equipment orproject databases and the tools which are felt necessary to manage the data.
1INTRODUCTION

A considerable amount of information has to be provided, stored and exchanged during the various phases of alarge project, like the LHC accelerator. Powerful database management systems are now available and ease theorganisation and storing of this data. But retrieval or manipulation tools are as important as the database engine
itself.
The required information varies during the project lifetime, as does the necessity to share this information. This
paper tries to identify the information required to design, produce, install and eventually commission the vacuum
system of LHC. It will also focus on those areas where information may not be available in the most suitable way.
2CONCEPTUAL DESIGN PHASE

The functionality of the equipment must be defined properly during the conceptual design phase, but thecomponents of the various systems, including the vacuum system, are only loosely defined. The aim at this stage isto provide a feasibility study, along with cost and resource estimates. This activity is carried out based on experience
with previous accelerators, prototypes, manufacturers' catalogues, etc. In the case of the vacuum system, layout
sketches are the primary input for the topology. From these, the vacuum specialists evaluate requirements forpumps, valves and measuring equipment. Adding them all together will provide a cost estimation.
During this phase, it is important to have access to the design and manufacturing data of previous accelerators(e.g. LEP), as well as to up-to-date supplier documentation. At CERN, design and manufacturing data from previous
accelerators exists mainly in the form of paper reports and drawings, the latter often being stored in EUCLID orAUTOCAD format. Some manufacturing data for vacuum chambers exists in the form of ORACLE tables. On theother hand, manufacturers' catalogues are beginning to be published on electronic media, such as CD-ROM disks,
which can be accessed from desktop computers.
At this stage, sharing of data is mostly done during formal and informal meetings. Minutes of these meetingscan (and start to be) published by electronic means, like the World Wide Web. There is little need for a central
database and in most cases a good spreadsheet program is an adequate tool to rapidly evaluate the cost of varioussolutions.
However, at the end of the conceptual design phase the cost and resource estimates should be stored in a central
database, as they are key components for the planning and the follow-up of the budget and expenditure.
3DETAILED DESIGN PHASE

The requirement for storing and sharing data considerably increases during the detailed design phase. The primary
input data is the layout of the accelerator, which is derived from the conceptual design and gets more and morerefined. The level of detail required is however varying strongly, depending upon the usage. For instance, thevacuum specialist responsible for distributing the pumping equipment needs to know about possible interferenceswith other equipment, whereas the controls team only needs to know the location of the equipment for cabling.
The layout data must allow for version handling, as it must be possible to work on several different
implementations simultaneously. A good example of the implementation of such a database is given in [1]. It has
been widely used by the Vacuum Group for the LEP accelerator. However, there is a strong need for better tools toaccess and manipulate the data.

Layouts are best represented on drawings rather than lists of equipment. The main reason for this is that thesedrawings are presented to various decision committees, where discussions in front of a computer screen are not easily
possible. Another, almost trivial, reason is that the human eye often points to possible interferences much quicker
than sophisticated analysis programs. Modifications of layouts should be possible using tools which resemble object
drawing programs rather than the present method of ORACLE Forms used by Vacuum Group.
The objects themselves are drawn by the design offices using CAD tools (mainly EUCLID and AUTOCAD atCERN) and should be stored with various levels of details in a central database. The relations between the objects
also have to be stored in a database. Work is going on in this field in the Vacuum Group and elsewhere at CERN[2], aiming at a generalised approach for defining and grouping objects.
It should be possible to access and manipulate these objects on a screen using essentially a "point and click"approach. For instance, the vacuum specialist in charge of placing the pumping elements would display a section of
the layout of LHC and add or displace the pumps, the model of which would have been drawn by the design offices orextracted from manufacturer's documentation, when available. Again by analogy with common drawing programs,
the layout should be drawn in layers corresponding to the various equipment groups.
Not all data has to be entered manually into a database. A large accelerator like LHC has a highly repetitive
lattice for more than three quarters of its circumference. Hence automatic programs can be used to enter data likepump locations and the associated cabling. This approach was successfully used for LEP, where the initial cablingand routing had been produced automatically from the available description of the vacuum system in an ORACLEdatabase. Similarly, pumps, gauges and roughing valves have been automatically placed using a FORTRAN
program, the input of which was again the description of the vacuum system extracted from the database.
A large amount of experimental data will be produced during the detailed design phase. Several experiments are
run to evaluate the effect of synchrotron light and the way to cope with it in a superconducting environment [3].
This data should be stored, but do not necessarily have to be in central database, as it is highly specialised.
As the volume of data increases considerably during the detailed design phase, it becomes necessary to introduce
global data management tools, often referred to as Engineering Data Management Systems (EDMS). Commercialproducts start to be available and used in industry. An EDMS Task Force has been set up at CERN to try to use
such a product for the design of LHC experiments [4].
4MANUFACTURING OF COMPONENTS OF THE VACUUM SYSTEM

The Vacuum Group's involvement during the manufacturing process is mainly related to the tendering process,the follow up of the fabrication and the acceptance tests. At this stage all possible critical paths should be identified.
Planning data must therefore be easily available and updatable. A solution to this problem is proposed in [5].
During the tendering process, detailed drawings must be made available from the design offices. In general, thesedrawings are produced using CAD tools but they still are output on paper, although more and more industries use
CAD programs with an interchangeable output format, like AUTOCAD. An up-to-date supplier database is also akey ingredient for successful tendering, in particular to minimise the need for time consuming Market Surveys.
During the follow up of the manufacturing, critical data, such as tolerances, must be obtained from themanufacturers and stored in a database at CERN. During the construction of LEP, manufacturing data of the leadcladding process were downloaded from the supplier in Germany over telephone lines and stored in ORACLE tables.
It is also at this stage that inventory data, like serial numbers, start to appear. Finally, the results of the acceptancetests must also be stored. The approach proposed in [2] seems adequate to relate the data properly with the differentobjects being manufactured. However, here again, a considerable effort to ease data input and retrieval has still to bedone. In particular, it should be avoided as much as possible that data produced at the manufacturer's place has to beprinted and later typed into a database.
5INSTALLATION AND COMMISSIONING

During the installation phase, the primary data required is layout, planning and stock keeping. During thisphase, there is little input from the Vacuum Group, except for delivery time of components and feedback frominstallation teams. But there is a considerable need for planning and logistics information.
The location of every component, identified by some serial number, should be recorded during installation. Thisdata can be of great use when defects appear which could be linked to a particular series or production time of somecomponents, requiring systematic repairs or modification. An attempt to store the location of vacuum equipment
was started in LEP, where bar code labels were glued on the vacuum chambers prior to installation. A programmablebar code reader was used to scan parts of the accelerator after installation and this data was then loaded over RS-232
lines into the database computer. Unfortunately, the scan was never finished and the data has not been used. There
was no technical problem, however.
The quantity of data to store increases again when the time comes for commissioning. At this stage, the maincontrol system for LHC should be available. Hence, this data could be automatically fed into the database using datalogging and archiving programs. This data is crucial for the future maintenance activities of the accelerator. Becauseof the tight time schedule of the installation work, some minor defects may have to be left for a later repair. The
commissioning data would allow for a map to be produced of the temporary repairs which have to be fixed at the firstpossible occasion.
6CONTROLS AND OPERATIONThe specific database requirements for controls are multiple and start during the detailed design phase. Initially,
the cabling of all remotely controllable equipment must be defined, relying on the layout data and properties of theequipment. As already mentioned, a large part of this activity can be done using automatic programs. In theexploitation phase, however, when only incremental modifications are done to the accelerator, a graphical approach ispreferred.
An important effort has been made to provide operational models for the vacuum equipment [6]. These models
are best described using object oriented notations. Thus, an object oriented database is likely to be the most efficientrepository for the description of the properties and behaviour of the vacuum equipment. Work is presently going onin the Vacuum Group to assess to what extent a conventional relational approach could be used until commercial
object oriented databases really exist. The messages and the required parameters used to drive the equipment mustalso be stored in the database. This has been done for LEP and allows for a coherent behaviour of the equipment, as
well as for automatic decoding of the messages [7].
Finally, as soon as part of the accelerator come into operation, the pressures should be logged. Unlike allprevious databases, this requires an on-line database, with update or insert times compatible with the physical dataacquisition. Extracting data can be done off-line, however. Data reduction and archiving algorithms should be madeavailable as soon as some data is available from the vacuum system via the main control system. A typical logging
system should gather data at a relatively high rate (e.g. one reading every few minute). This data must remain
accessible for a period of time of the order of one or two weeks, after which only a subset should be stored and kept
for the lifetime of the accelerator.
7CONCLUSIONSThe presently used Data Base Management System, ORACLE, is adequate for the storage of the huge amount ofinformation required for the design, construction and commissioning of the LHC accelerator. Most effort will haveto be put in the data manipulation tools, in particular to allow for a more graphical approach. A significant effortwill also have to be put into the Configuration Management and into the global management of all this data, using
the emerging commercial Engineering Data Management Systems.

REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]

CERN's Accelerator Description Using Databases, A. Albrecht et.al., proceedings of the 9th International
European ORACLE User Group Conference Cannes, 1992, CERN SL/92-19 (OP)J. Schinzel, private communication, CERN-1994R.Calder at al., Synchrotron Radiation Induced Gas Desorption from a Prototype LHC Beam Screen at
Cryogenic Temperature, CERN AT/95-42 (VA), LHC Project Note 7
C. Hauviller, chairman of EDMS Task Force, private communication, CERN-1995
A Planning and Scheduling System for the LHC project, G. Bachy et al., LHC Note 355
Operational Protocols for Vacuum Systems, G. Baribaud at al., CERN AT-VA (91-06)
Automatic decoding for the control messages for the LEP Vacuum System, P.M. Strubin, proceedings of the8th International European ORACLE User Group Conference, Madrid, 1990, CERN AT-VA (90-93)