- Email: [email protected]
Accelerator controls at CERN: Some converging trends
308
Nuclear Instruments and Methods in Physics Research A293 (1990) 308-315 North-Holland
Section X. Standardization and protocols
ACCELERATOR CONTROLS AT CERN: SO
CONVE GING
NIES
B. KUIPER
CERN, CH-1211 Geneva 23, Switzerland
CERN's growing services to the high-energy physics community using frozen resources has led to the implementation of "Technical Boards", mandated to assist the management by making recommendations for rationalizations in various technological domains. The Board on Process Control and Electronics for Accelerators, TEBOCO, has emphasized four main lines which might yield economy in resources. First, a common architecture for accelerator controls has been agreed between the three accelerator divisions. Second, a common hardware/software kit has been defined, from which the large majority of future process interfacing may be composed . A support service for this kit is an essential part of the plan. Third, high-level protocols have been developed for standardizing access to process devices. They derive from agreed standard models of the devices and involve a standard control message. This should ease application development and mobility of equipment. Fourth, a common software engineering methodology and a commercial package of application development tools have been adopted. Some rationalization in the field of the man-machine interface and in matters of synchronization is also under way.
1. Situation early in 1987 Early in 1987, accelerator controls at CERN seemed to be divided into three separate worlds . There were two major controls clusters : the PS complex and SPS were each fairly consistent internally but mutually incompatible. A third large system, LEP, was in an advanced state of construction and, in spite of early intentions to the contrary [1], its control system differed from the two earlier ones . The first two were operating successfully and the third would no doubt also be a success. The investments in either of the earlier ones amounted to several tens of millions of Swiss Francs, making well over one hundred million in total. Manpower investment amounted to several hundreds of man-years, of which at least 300 man-years was in applications software, without counting LEP applications, which had not yet started. The hardware and software architectures of the three systems were different. SPS, the first large-scale integrated control system at CERN [2], featured a network of Norsk-Data 16-bit minicomputers running the Isynt on operating SySLca1L, MI iii-uUUSC UCVCYC)PMCnt C)! an early version of the manufacturer's product. Computers were linked by a star packet-switching network (TITN), custom-made by an industrial firm . Programming languages were the in-house developed interpreter NODAL and assembler. Later, NPL, the manufacturer's structured assembler and FORTRAN were introduced . The consoles were in-house developments, consisting of a set of display and interactive devices separately interfaced to their minicomputers. The process interface
used a combination of CAMAC and an in-house developed serial transmission called MPX. The SPS North experimental zone used serial CAMAC. The second system was the updated controls of the PS complex [3]. The architecture was inspired by the SPS and adopted a number of facilities from that system, such as the Norsk-Data 16-bit minicomputers, the networking system TITN with its dedicated software, and the NODAL interpreter . Console hardware was similar to the SPS, but used later developments . However, allowance had to be made for the different nature of the process . The shorter cycle and the need for pulse-to-pulse parameter changes had consequences in the hardware layout and, above all, in the software structures. There were several modifications with respect to the SPS . Compiled languages were introduced from the start, in addition to NODAL: NPL for system software and PASCAL and P + (a home-made extension of PASCAL) for applications . A software skeleton had to be set up to support the specific application programs for parameter refreshment and other real-time tasks. The interface was serial CAMAC with Texas instruments 9900, 16-bit microprocessors in most crates, responsible for parameter refreshment and buffering data acquired from the instrumentation. For the LEP pre-injector [4], the Motorola 68000 32-bit microprocessor replaced the TI 9900 in the CAMAC and this aook over some of the tasks of the minicomputer. After commissioning the controls of the LEP pre-injector, decisions had to be made about the future of the PS control system . TITN network maintenance was gradually becoming a problem, while international standards,
0165-92/90/$03 .50 © 1990 - Elsevier Science Publishers B.V . (North-Holland)
B. Kuiper / Accelerator controls at CERN
such as Ethernet and the token ring were becoming available. Workstations were also becoming available, as was VME, while CAMAC was aging. The design of the LEP control system [5] had been frozen and its construction was under way . It was based on Apollo workstations running UNIX and Aegis and on the IBM token-ring network using the TCP/IP protocols. For the process control level, a contract had been placed with Cimsa-Cintra for their VME-based system, called DLX, using the ELECTRE multiprocessor operating system running on Motorola 680XX 32-bit processors. Those crates would drive the specific control electronics at the device level over the MIL/STD-1553B field bus. At the system software level, MODULA2 had been chosen and the NODAL interpreter had been recoiled in that language. For applications development it was proposed that FORTRAN and PASCAL would be supported. C was just making its entry. The specific control electronics at the device level, now all intelligent devices, were the responsibility of the relevant process equipment groups, resulting in a variety of approaches in layout, hardware, processors, operating systems and programming languages, although the G64 bus was dominant and some VME was used. At least four major groups could be identified : power converters, beam instrumentation, radio frequency and vacuum. This diversity arose because the work started before the project was approved, but it upset the homogeneity of the higher-level design, and there will be a price to pay. Note that investment for the controls at this level is of the same order of magnitude as that for the control system itself. Finally, large turn-key installations such as the ventilation systems had their own industrial control systems which had been interfaced as satellite systems . Gateways were foreseen to connect the LEP system to the SPS system, and LEP was to be operated from the SPS Prevessin control room. Partly to achieve homogeneity with LEP, a strategy for retrofitting the SPS controls in the LEP style [6] had also been adopted. Access to the process devices at the lower level is determined by the relevant hardware and communication protocols, using the MIL/STD-1553B standard at LEP, CAMAC and MPX at SPS, and the CAMAC serial highway at the PS complex and in the SPS North experimental area. At a higher level of abstraction are the operational protocols, which show only the symbolic essentials to the operator and hide technical details such as the lower-level communications and technological aspects of the devices . Standardization of operational protocols assists in the applications development and maintenance and is a necessary condition for portability of process equipment . Although there were agreements about the high-level access protocols for each subsystem, there existed a variety of these at CERN . A standardization of power converter protocols, introduced
309
earlier at the PS [7], had proved highly rewarding and an initiative towards a wider standardization [8] was taken in 1986 by a few individuals at the PS and LEP. Application program development at CERN, like in many other laboratories, is a constant problem . Application software tends to be too little and too late. Three causes can be identified. Firstly the specification of an application is always late since the customers, such as machine physicists, and operations and process hardware specialists, usually start too late and thus do not allow enough time for design, implementation and testing. Secondly, the problem suffers from neglect by the management, often unwilling to acknowledge the manpower cost to provide a comfortable, modem programming environment. Thirdly, insufficient attention has been paid to rationalizing the applications through common code, templates, etc. in order to avoid disjointed programs and duplicated code. An example of such a rationalized approach is the device access package Tm:'-aPS, used at the PS [9] . Furthermore, timing and synchronization and the operational aspects of controls were treated differently from one system at CERN to another. 2. The formation of technical boards The state of diversity at CERN, described in the previous section, was by no way confined to the accelerator control field . Other major technological fields on which the construction of particle accelerators is based, such as power converters, beam instrumentation, radiofrequency, vacuum and mechanical engineering, showed similar differences. Nor was this state of affairs unique to CERN : other laboratories show similar signs, albeit on a smaller scale. This was the natural consequence of the way in which these laboratories had grown, expanding each time a new major construction project was undertaken . These projects, following each other at intervals of several years, each took advantage of the latest technologies and methods, so the variety of equipment installed and still operational at CERN today reflects the progress of technologies over about 30 years . For CERN this was a consequence of the way in which the organization had been managed during the first two decades of its existence . In the first twenty or .orld cvsr CERN _-____ ~-......~ " " "" --- (`AtchJL6+va36a world SO YGÜ , of in terms US laboratories with the leading ing up underlying advanced as the physics as well particle technology. Management was fairly liberal, often allowing several technological approaches to coexist or even to compete, with the aim of stimulating their development. Moreover, funding of nuclear- and particlephysics research was still relatively generous in all major industrial countries of the, world, and CERN had a unique position in Europe. l
the _ACa_E~11116 Z8
.mod
üJSàQ
X. STANDARDIZATION
310
B. Kuiper / Accelerator controls at CERN
During the third decade of CERN's existence, this favourable situation was changing. On one hand, CERN had reached a recognized world leadership in accelerator construction and particle physics . On the other, competition in Europe for public funds for the purpose of pure and applied science had become more intense, while some of the post-war gloss of particle physics was wearing off. In 1986, CERN was working with a level budget and a slowly declining staff, while providing a steadily growing service to the high-energy particlephysics community . This called for a different style. At the same time there was a debate inside the UK physics community, who, seeing most of their shrinking physics funds going to CERN, started questioning their membership in that organization. A consequence of this was the formation of the CERN Review Committee [10] called the Abragam Committee after its chairman, which was given the mandate to review the operation of CERN under the present budgetary conditions and under alternative, reduced budgets. On the technological side, CERN responded to these new challenges by, amongst other things, forming a number of Technical Boards with the mandate to make recommendations for rationalization in the major technological areas, with an eye on possible economies in the use of resources . These boards had no executive authority. The mandate [11] being formulated in extremely broad terms, it remained to the Technical Boards themselves to identify a number of goals with a realistic chance of success in a few years and in the prevailing CERN conditions . Opinions in the controls community varied . Some held that, since practically all the major decisions for LEP had recently been frozen, not very much could be expected by way of convergence until several years after LEP was commissioned . Nonetheless, the time looked propitious for a dispassionate look at our ways and methods, since it would not become subject to the traditional blackmail with delivery times ("either you let me do it my way, or it's your fault that I won't meet the deadlines") . Of course there would be no way of changing the things already under way . Nor would it be possible to make changes in existing installations in the near future, due to the very large investments required. But one could try to get agreement on a number of principles and goals, to which one could converoa eocirig e-erv racnrtaialp nnnnrt__h , . ., .. . ... .~,. ... . ... .. . ...) .e,"..mab .e vrr-tu ....., ___ ac ..... new installations or major rebuilds . With this in mind, two broad goals were set to get people on speaking terms with each other and to set a number of b` key switches to convergence". A first and essential step in the direction of convergence is to have a systematic exchange of experience between engineers and technicians at the working level. Before 1987, such exchange was sporadic, due to the organization by projects and divisions, geographical
separation, and also for purely human reasons . The emphasis on the working level means that involving only group leaders and division leaders would not suffice, so initiating this systematic dialogue between broader layers of controls people should receive the very highest priority. An essential condition for the convergence of methods and collaboration on common objectives is agreement on a reference frame of basic principles and boundary conditions. Until 1987, and even up to now, a number of existing conditions were impeding collaboration on common objectives. These were the different, and mostly incompatible, design options which had been taken early on, either to allow for technological change or through purely human causes. In those circumstances, delivery of the next development would always be faster and cheaper by following existing habits, at least when seen in the narrow local context . On the CERN scale, however, and taken over a number of years, this vicious circle has a price which we are now beginning to understand. The next highest priority was therefore to forge agreement on a sufficient set of basic principles to eliminate, in the medium term, these excuses for incompatibility .
3. Methods, topics In order to organize a systematic dialogue in broader layers of the controls population, the technical board TEBOCO had to be organized appropriately. In consultation with the group leaders for accelerator controls, a number of members were chosen for the board. They had to be open to new ideas, willing to take a CERNwide view and actively contribute to some convergence ; they had to have proven track records in some technical field(s) of accelerator controls, they had to have sufficient seniority, or some executive responsibility such as section leader, and then they should have mature judgement and a way with people. All divisions should be represented fairly . Each member of the board was expected to act as prime mover in one of the chosen fields of action (see below). For that purpose he was required to head a "chapter", a subcommittee of specialists in the field. Cin~rinitialler tr1~PTP ILPYP CPIrPI'~ !`hantrPrc aeraraoina cPVan
members each, this gave an involvement of around 50 specialists out of a total controls population at CERN of between 200 and 300 . This is in agreement with the objective of a broad involvement at the working level. Formal meetings were to be about 2 hours each month . Chapters were allowed to set up working parties for specific goals . The fields of action covered by the chapters and their specific objectives were:
B. Kuiper / Accelerator controls at CERN
Control system architecture : to investigate unifying principles and try to agree on a reference frame for future convergence in methods and for collaboration on common goals; to review proposals of the other chapters on a total-system basis. Specific control electronics : to explore the possibility of common methods and products for future process interfacing and make proposals for a hardware-software kit with an accompanying support service. Operational protocols : to explore the possibility of convergence in high-level access protocols to process equipment and to make proposals for CERN-wide protocols for each category of equipment . Applications software : to explore the possibilities of rationalization of the applications development process and propose common methodologies and common high-level tools . Programming environment : to review the needs for the programming environment and propose a basic but comfortable set of (preferably commercial) packages to provide for those needs and give guidelines on their use . Operational aspects : to review the principles and styles of man-machine interfaces and make suggestions for unifying principles. Timing and synchronization : to survey inter-accelerator timing, with a view to overall coherence and reliability, and suggest improvements and unifying principles. Technology and workshops : this was a joint chapter with the Technical Board for Electronics for Research, TBER. Its objectives were to suggest a CERN-wide approach on CAD/CAE, on the introduction of new electronics technology and on electronics assembly workshops inside CERN . The chapter was soon dissolved, pending reorganization in the research sector. 4. Results 4.1. Control system architecture Surprisingly, progress in this field, which initially seemed to have the strongest historical constraints, was spectacular. The event which opened the door for convergence in system architecture was the collapse, early in 1988, of the LEP contract for a VME-based multiprocessor system (DLX) and its operating system iT 1C`TD E
A A- ;o;nn
then tnI,Pn
t(1
phiO the- onn
by using IBM-compatible PC/AT computers on the token-ring network to control the VME crates containing the MIL/STD-1553 drivers. A few months of reflection yielded a compromise [121 between the controls groups of LEP/SPS on the one hand and that off PS on the other. That compromise involved a choice of open systems, in contrast to proprietary ones. It also involved a stated preference for mature commercial systems over custom- or home-made ones, but not formally excluding
Workstations
Server(s)
PS :
SPS/LEP:
APBLLO VAX UNIX U PS : ULTRIX both : X-Windows DEC-®Vindows
Backbone LAN Bridle Regional LAN
PS . SPS/LEP. Token-Ring Ethernet both : TCP/IP
SiNple Instruwentatiiu
Fig. 1. Simplified hardware architecture for CERN accelerator control . the latter . At the workstation level, PS would drop their former choice of the VMS operating system and would use ULTRIX. In turn, SPS/LEP agreed to move to pure UNIX V in their Apollo workstations, proposing to drop their (partial) dependence on the proprietary Aegis system . Both parties agreed to use XWindows and DEC Windows and would jointly explore possibilities of using other industrial packages, such as DVDraw/DV-Tools etc ., and possibly adapting home-made ones (e.g. the DataViewer from SPS) to Windows. At the process control level, where real time is an issue, both parties agreed to use VME, the Motorola 680XX family of processors and the OS-9 real-time operating system, allowing native software development and cross development. For networking, the emphasis was on the communications protocol, since that governs much of the possible software compatibility . It was agreed to use TCP/IP in both cases, on Token Ring at the SPS/LEP and on Ethernet at the PS. Although the network hardware is different, as is appropriate to the two environments, the common protocol will allow easy communication and opens the door to joint projects and products. The agreed hardware architecture is depicted in fig. 1 and the software architecture is given very schematically in fig. 2. At LEP, and therefore later also at SPS, the VME/MC-680XX/OS-9 combination would replace the present PC/AT, XENIX Systems . At the PS a transition strategy was devised, allowing a migration X. STANDARDIZATION
B. Kuiper / Accelerator controls ai CERN
31 2
that a large majority of specific control electronics could henceforth be synthesized from one judiciously composed hardware and software kit, called the SCELKit . Agreement was also reached on the nature of that kit and of a support service which was proposed by a specially mandated working party [13]. A recommendation was issued to the management to implement the use of this kit and set up the service. It is hoped that this will become effective early next year.
Analysis, Design, Management, Compiler
Application Builder
Test A Diagnostics Builder
Programing Environnent
operating System's
M F S
Task Execution Environment Remote File Access
Data
Du
Viewer
Draw
DEC-Yindows X-Vindows
Primitives
4.4. Operational protocols R P C
TCP/IP Operating System Hardware
Fig. 2. Simplified software architecture for CERN accelerator control.
from the present system to the new CERN architecture . After these decisions were made late in 1988, six joint working parties have started to elaborate the details and have made good progress . 4.2. Programming environment
The options tAen in the field of software architecture mainly determine the programming environment . On the workstation side, this is the UNIX environment with C as a language, and on the process side, the same C language in an OS-9 environment . For the latter there is the native environment and a cross-development possibility from the CERN central facilities. In addition, FORTRAN will be supported for certain applications. The NODAL interpreter will be conserved for troubleshooting and fast prototyping and is being recoded in C. The possibility of using so-called "integrated development environments", such as for ADA, has been reviewed, but a decision must wait for further maturing . One may not have attained the ultimate in comfort, therefore, but in compensation there is clarity, some measure of integration and a considerably reduced diversity for programmers . 4.3. Specific control electronics
In this field, the initial timid hopes have been realized. After a systematic review of the various methods and product choices at the equipment level, and of the various satellite control systems, consensus was reached
The working party for power converters reached a consensus on an operational model which could represent the overwhelming majority of power converters at CERN. A control message derived from that model was then proposed. A detailed document [14] was issued, describing the model and the message . A new kickermagnet system at the SPS will incorporate these protocols and evaluate their practicality. For beam instrumentation, the same exercise was undertaken by a small working team, and a model and a message have been proposed [15]. The opportunity of a rebuild was taken to prototype the proposals on a system of beam transformers for the PS booster. The system is now starting to work [16] and first results are encouraging. Paradoxically, it seems likely that one operational model may satisfy the requirements for the majority of beam instruments. Moreover, the proposed messages for instruments and power converters have the same morphology [17]. The working party for vacuum protocols started their study in the spring of this year, since the vacuum groups of both the PS and the SPS plan to completely refurbish their specific control electronics. This line of development has drawn interest from other laboratories and collaboration on operational protocols is under way with seven European laboratories [18]. This is being organized by members of the working party under the auspices of the EPCS, the European Physical Society's interdivisional group for Experimental Physics Control Systems . 4.5. Application software As a first priority . the chapter concentrated on introducing, for accelerator application development, a methodology for computer-aided software engincer1ng (CASE), as pioneered at ÇERN in the FP and SPS divisions . Consensus was reached on a common software tool package, Teamwork from CADRE [19], and advantageous terms were obtained for CERN and affiliated organizations, as well as for EPS-EPCS-affiliated organizations in Europe . On the initiative of the ORACLE data-base users group for accelerator applications, SQL, *NET was recommended as a standard for access from LEP controls to the LEP ORACLE data
B. Kuiper / Accelerator controls at CERN
base on the VAX cluster . With a view to further rationalization, the chapter is presently engaged in a systematic analysis [201 of certain categories of software packages existing at the three CERN accelerators . These packages represent either application-oriented functionalities (not code) common to several accelerators, or tools for producing specific application software. The study is concentrating on identifying how far these programs, or parts thereof, must depend on the accelerator and/or controls environment in question . The aim is to find programs that could be, or could become, transportable and thereby common to the CERN accelerators. These hopes have been refuelled by the adoption of the common CERN software architecture. Contacts with other laboratories are also being maintained on this theme, under the auspices of EPS-EPCS. 4.6. Timing and synchronization Inter-accelerator timing problems were reviewed and additional diagnostic equipment was specified and is under construction. The 1 kHz timing signal is now being derived from the clock at the SPS and distributed to the PS. A suggestion for a CERN-wide supercycle programming system was thought to be premature. The same date-and-time tagging system for identification of beam instrumentation measurements is now available at all accelerators . 4.7. Operational aspects The operational habits relevant to controls were reviewed and a colour code for displays wa.~ agreed. The use of the industrial software package DV- .`raw/ DVTools was recommended for certain classes of applications such as general services and vacuum . The conversion to workstations at the PS complex will involve substantial rewriting of application software and an operational specifications study has been launched using the combined CERN experience in this field . In particular, an exercise in high-level structuring of process and data will be made, as pioneered at LEP [211. 5. Reflections, discussion -la-_ 1L_ d-_, 1___ aL_ tb__GG_ ., .s: . .- .,.0 mL . . 1 ~Qdy LIli1 Â LIIi yGiliba1LG1 t11%; bâCatiVlt vi tale
less Technical Board, the situation for accelerator con±rols at CERN has changed drastically : (1) c systematic dialogue within the controls population has become a reality and (2) the relevant key switches have been set to allow further convergence . The physical state of the control systems is still very much like that early in 1987, with the exception of LEI', which has meanwhile become operational, with the control system [22] decisively contributing to a smooth
31 3
start-up. Instant unification is of course out of the question because of the massive investment that would be required. However, the change in style and objectives, with respect to earlier CERN working habits, has been dramatic. It is emphasized that only the switches are set and that the process of convergence is only starting. A prolonged, imaginative and above all motivated effort at all levels has to be made in order to transform into a mature and robust structure what is now at best a seedling. Consensus is a very fragile seedling; it tends to decay if not adequately nourished and protected . This places the responsibility squarely on the CERN management; they must make the resources available for consolidation and only they can keep the torch burning by combining encouragement with a firm hand! Although the seedling is fragile at the moment, the potential can hardly be overestimated . One unexpected illustration of that potential came when, upon hearing of the CERN plans, two other laboratories, Sincrotrone Trieste and ESRF Grenoble, spontaneously asked to join the working groups. They have made a contribution which yields a modest but real saving for CERN. If the road now taken is consistently followed, then the savings in the 1990s, compared with CERN's earlier working style, could be counted in tens of millions of Swiss Francs . More than that, the users should be better served and life for the controls people may b, .-come more fascinating : instead of reinventing the same thing in multiple flavours, they will be working on real innovation . To conclude, we give some comments on the experience gained and some conclusions drawn when working together in TEBOCO . Contrary to expectations, the atmosphere at the working level - up to group leader - has been surprisingly positive and constructive from the start. Even persons reputed to go their own way showed a willingness to try a new approach . Many persons have spontaneously joined the working parties and even spent their spare time on elaborating proposals . Middle management - group leaders and division leaders - had more reservations. Obviously, a horizontal coordinating structure making recommendations to the technical director has built-in contradictions with the vertical hierarchy . In addition, a certain percentage e~â nnA the Vl oé~~r$ V " mtim4 cvara$ svaam in$cT~A~~~ mamcv nar+vvv ILAr~C """ + . .~------ real -----
nerg---
centages were the object of some dispute . Some mild friction was relatively frequent, a few skirmishes were fenced out in more detail or were postponed and, of course, the question "who is in charge here?" was repeatedly heard. Top management - the technical director and above - gave their due support in verbal encouragement to the TEBOCO Board and also to the chapters. The technical director spent the time he could afford. At the board }C. STANDARDIZATION
31 4
B. Kuiper / Accelerator controls at CERN
level this was not always felt to be adequate. Indeed, what TEBOCO was mandated to do, stated in caricature, was to disentangle in a few years a jungle which had happily vegetated over two or three decades . This is only possible with very active support from the top . The job has therefore been frustrating at times, but the challenge, and the strong stimulus of the believers, and finally the results, have handsomely compensated for the sufferings. It is our considered opinion that these jobs could be done more efficiently with an executive mandate. Division leaders and group leaders are eminently reasonable and will work together when having an explicit mandate to do so. Last, but not least, it should be said that some of the problems would not tend to appear at all if the controls groups were united into one horizontal controls service. Although some other problems would then certainly arise, in times of insufficient resources that structure seems preferable . For that reason TEBOCO has made a recommendation in favour of an integrated controls setup [23] for all CERN accelerators . Acknowledgements It is a pleasant duty to thank all those persons who, with much good will and enthusiasm, and often in their spare time, have contributed to the rationalizations by placing their experience at the disposal of the others and by working out concrete proposals for convergence. Their names are listed below. - TEBOCO Board : J. Altaber, G. Baribaud, L. Burnod, A. Daneels, B. Kuiper (chairman), M. Rabany, R. Rausch and G. Shering. - Chapter on system architecture : J. Altaber, F. Di Maio, F. Perriollat, M. Rabany, R. Rausch (chairman) and C.-H. Sicard. - Chapter on specific controls electronics : P. Burla, G. Cavallari, E. Ciapala, J . Dieperink, R. Flockhart, A. Guyard-Marigny, W. Heinze, C. Jacot, M. Rabany (chairman), R. Rausch, P. Strubin and A. Swift. - Chapter on operational protocols : R. Bailey, G. Baribaud (chairman), G.P. Benincasa, P. Burla, G. Coudert, G. Gelato, H. Kuhn and R. Saban. - Chapter on application software : P. Andersen, L. Casalegno, J. Cuperus, A. Daneels (chairman), L. Jirden, G. Kellner, R. Keyser, J. Lewis, Ch. Serre and . Tyrrell . Chapter on programming environment : J. Altaber (chairman), P. Andersen, L. Casalegno, N. De MetzNoblat, J. Miles and F. Perriollat. Chapter on timing and synchronization: G. Baribaud, G. Beetham, J. Boillot, .ï. Boucheron, L. Burnod (chairman), G. Daems, R. Lauckner, J. Lewis and J.-P. Riunaud .
Chapter on operational aspects : M. Boutheon, G. Daems, L. Evans, A. Faugier, G. Guignard, V. Hatton, J.-P . Potier and G. Shering (chairman). - Working party on "power converter protocols": J. Bonthond, P. Burla (chairman), G. Coudert, A. Fowler, D. Grier, H. Henrichsen, H. Kuhn, R. Maccaferri, G. Mugnai, R. Pittin, P. Schneckenburger and J.-P . Royer. - Working party on "vacuum protocols": M. Bourgeois, B. Desforges, L. Henny, P. Strubin (chairman), D. Swoboda and G. Baribaud . - Working party on "beam instrumentation protocols" : R. Bailey, G.P. Benincasa (chairman), L. Casalegno and G. Gelato. - Working party on "hardware/software SCEL kit": A. Ball, P. Brummer, A. Chapman-Hatchett, E. Ciapala, G. Coudert, C. Eck, R. Flockhart (chairman), J. Gamble and G. Molinari . Last but not least, our Technical Director, Giorgio Brianti, who instituted the system of technical boards, had to endure various problems, patiently smoothing out numerous minor conflicts which inevitably arise from the inherent contradictions between the vertical executive hierarchy and a horizontal coordination structure. We thank him for his encouragement and for his efforts towards making possible this undertaking. -
References [1] M.C. Crowley-Milling, The Control System for LEP, DGDI/MCCM/tr (17 Nov. 1980) . [2] M.C. Crowley-Milling, The Design of the Control Systcrn for the SPS, CERN 75-20 . [3] G. Baribaud et al., IEEE Trans . Nucl. Sci . NS-26 (1979) 3272. [4] B. Kuiper (for the PS controls Group), IEEE Trans. Nucl. Sci. NS-32 (1985) 2044. [5] P.G. Innocenti, Proc. Europhys. Conf. on Control Systems For Experimental Physics, Villars, 1987, CERN Yellow Report, to be published . [6] J. Altaber, Proc. 13th Int . Conf. on High Energy Accelerators, Novosibirsk, Aug. 1986 (Nauka, Siberian Division, Novosibirsk, 1987) vol . 2, p. 207 . [7] E. Asseo et al., IEEE Trans. Nucl. Sci. NS-26 (1979) 3319. [8] G. Baribaud, P. Burla, A. Daneels and J. Pett, Control Methodology for Accelerator Power Converters, LEPPC/JGP/rl (February 1987). [9] L. Casalegno et al., Proc. 7th IFAC Workshop, Mayschoss/Bad-Nauenahr, Sept./Oct . 1986 (Pergamon Press, 1986) p. 143. [10] A. Abragam et al., Final Report of the CERN Review Committee, CERN 1676 (3 Dec. 1987). [11] G. Brianti, Technical Boards, Terms of Reference, CERN (1986) . [12] J. Altaber, F. Perriollat and R. Rausch, Proposal for Active Collaboration and Convergence between Accelerator Control Systems, SPS internal note (5 Sept. 1988).
B. Kuiper / Accelerator controls at CERN [131 R. Flockhart, Hardware/Software SCEL-KIT for Specific Accelerator Controls Electronics, a report to the SCEL chapter of TEBOCO (rev. Oct. 1989). [141 J. Bonthond et al., Specification for a Control Protocol for Power Converters, PS/CO/WP 88-23 (rev. 2) (draft of 23 Jan. 1989). [151 R. Bailey, G. Benincasa and G. Gelato, Control Protocol for Accelerator Instrumentation: A First Approach, PS/CO/Note 88-24. [161 G. Benincasa et al., Implementation of a Control Protocol in the Instrumentation Field, these Proceedings (Int . Conf . on Accelerator and Large Experimental Physics Control Systems, Vancouver, BC, Canada, 1989) Nucl . Instr . and Meth. A 293 (1990) 338. [171 G. Benincasa, P. Burla and L. Casalegno : Final Convergence of the Power Converters and Instrumentation Control Protocols, PS/CO/WP 88-27 (10 Nov. 1988).
31 5
[181 A. Daneels, Interdivisional Group Experimental Physics Control Systems, Europhys . News 20 (1989) 110. [191 A. Daneels and G. Kellner, these Proceedings (Int . Conf. on Accelerator and Large Experimental Physics Control Systems, Vancouver, BC, Canada, 1989) ',Jucl . Instr . and Meth . A293 (1990) 382. [201 A. Daneels, ibid., p. 325. [211 C. Fisher et al ., Report on the Principles, Contents and Conventions of the Analysis Made by the LEP Applications Analysis Working Group (AAWG), LEP note 597 (22 Dec. 1987) . [221 P.G . Innocenti, The LEP Control System : Architecture, Features and Performance, CERN SPS/89-35(ACC); presented at the Int. Conf . on High Energy Accelerators, Tsukuba, Aug. 1989 . [231 B. Kuiper (for TEBOCO), Abragam and All That, memorandum to G. Brianti (2 Nov. 1987).
X. STANDARDIZATION
Nuclear Instruments and Methods in Physics Research A293 (1990) 308-315 North-Holland
Section X. Standardization and protocols
ACCELERATOR CONTROLS AT CERN: SO
CONVE GING
NIES
B. KUIPER
CERN, CH-1211 Geneva 23, Switzerland
CERN's growing services to the high-energy physics community using frozen resources has led to the implementation of "Technical Boards", mandated to assist the management by making recommendations for rationalizations in various technological domains. The Board on Process Control and Electronics for Accelerators, TEBOCO, has emphasized four main lines which might yield economy in resources. First, a common architecture for accelerator controls has been agreed between the three accelerator divisions. Second, a common hardware/software kit has been defined, from which the large majority of future process interfacing may be composed . A support service for this kit is an essential part of the plan. Third, high-level protocols have been developed for standardizing access to process devices. They derive from agreed standard models of the devices and involve a standard control message. This should ease application development and mobility of equipment. Fourth, a common software engineering methodology and a commercial package of application development tools have been adopted. Some rationalization in the field of the man-machine interface and in matters of synchronization is also under way.
1. Situation early in 1987 Early in 1987, accelerator controls at CERN seemed to be divided into three separate worlds . There were two major controls clusters : the PS complex and SPS were each fairly consistent internally but mutually incompatible. A third large system, LEP, was in an advanced state of construction and, in spite of early intentions to the contrary [1], its control system differed from the two earlier ones . The first two were operating successfully and the third would no doubt also be a success. The investments in either of the earlier ones amounted to several tens of millions of Swiss Francs, making well over one hundred million in total. Manpower investment amounted to several hundreds of man-years, of which at least 300 man-years was in applications software, without counting LEP applications, which had not yet started. The hardware and software architectures of the three systems were different. SPS, the first large-scale integrated control system at CERN [2], featured a network of Norsk-Data 16-bit minicomputers running the Isynt on operating SySLca1L, MI iii-uUUSC UCVCYC)PMCnt C)! an early version of the manufacturer's product. Computers were linked by a star packet-switching network (TITN), custom-made by an industrial firm . Programming languages were the in-house developed interpreter NODAL and assembler. Later, NPL, the manufacturer's structured assembler and FORTRAN were introduced . The consoles were in-house developments, consisting of a set of display and interactive devices separately interfaced to their minicomputers. The process interface
used a combination of CAMAC and an in-house developed serial transmission called MPX. The SPS North experimental zone used serial CAMAC. The second system was the updated controls of the PS complex [3]. The architecture was inspired by the SPS and adopted a number of facilities from that system, such as the Norsk-Data 16-bit minicomputers, the networking system TITN with its dedicated software, and the NODAL interpreter . Console hardware was similar to the SPS, but used later developments . However, allowance had to be made for the different nature of the process . The shorter cycle and the need for pulse-to-pulse parameter changes had consequences in the hardware layout and, above all, in the software structures. There were several modifications with respect to the SPS . Compiled languages were introduced from the start, in addition to NODAL: NPL for system software and PASCAL and P + (a home-made extension of PASCAL) for applications . A software skeleton had to be set up to support the specific application programs for parameter refreshment and other real-time tasks. The interface was serial CAMAC with Texas instruments 9900, 16-bit microprocessors in most crates, responsible for parameter refreshment and buffering data acquired from the instrumentation. For the LEP pre-injector [4], the Motorola 68000 32-bit microprocessor replaced the TI 9900 in the CAMAC and this aook over some of the tasks of the minicomputer. After commissioning the controls of the LEP pre-injector, decisions had to be made about the future of the PS control system . TITN network maintenance was gradually becoming a problem, while international standards,
0165-92/90/$03 .50 © 1990 - Elsevier Science Publishers B.V . (North-Holland)
B. Kuiper / Accelerator controls at CERN
such as Ethernet and the token ring were becoming available. Workstations were also becoming available, as was VME, while CAMAC was aging. The design of the LEP control system [5] had been frozen and its construction was under way . It was based on Apollo workstations running UNIX and Aegis and on the IBM token-ring network using the TCP/IP protocols. For the process control level, a contract had been placed with Cimsa-Cintra for their VME-based system, called DLX, using the ELECTRE multiprocessor operating system running on Motorola 680XX 32-bit processors. Those crates would drive the specific control electronics at the device level over the MIL/STD-1553B field bus. At the system software level, MODULA2 had been chosen and the NODAL interpreter had been recoiled in that language. For applications development it was proposed that FORTRAN and PASCAL would be supported. C was just making its entry. The specific control electronics at the device level, now all intelligent devices, were the responsibility of the relevant process equipment groups, resulting in a variety of approaches in layout, hardware, processors, operating systems and programming languages, although the G64 bus was dominant and some VME was used. At least four major groups could be identified : power converters, beam instrumentation, radio frequency and vacuum. This diversity arose because the work started before the project was approved, but it upset the homogeneity of the higher-level design, and there will be a price to pay. Note that investment for the controls at this level is of the same order of magnitude as that for the control system itself. Finally, large turn-key installations such as the ventilation systems had their own industrial control systems which had been interfaced as satellite systems . Gateways were foreseen to connect the LEP system to the SPS system, and LEP was to be operated from the SPS Prevessin control room. Partly to achieve homogeneity with LEP, a strategy for retrofitting the SPS controls in the LEP style [6] had also been adopted. Access to the process devices at the lower level is determined by the relevant hardware and communication protocols, using the MIL/STD-1553B standard at LEP, CAMAC and MPX at SPS, and the CAMAC serial highway at the PS complex and in the SPS North experimental area. At a higher level of abstraction are the operational protocols, which show only the symbolic essentials to the operator and hide technical details such as the lower-level communications and technological aspects of the devices . Standardization of operational protocols assists in the applications development and maintenance and is a necessary condition for portability of process equipment . Although there were agreements about the high-level access protocols for each subsystem, there existed a variety of these at CERN . A standardization of power converter protocols, introduced
309
earlier at the PS [7], had proved highly rewarding and an initiative towards a wider standardization [8] was taken in 1986 by a few individuals at the PS and LEP. Application program development at CERN, like in many other laboratories, is a constant problem . Application software tends to be too little and too late. Three causes can be identified. Firstly the specification of an application is always late since the customers, such as machine physicists, and operations and process hardware specialists, usually start too late and thus do not allow enough time for design, implementation and testing. Secondly, the problem suffers from neglect by the management, often unwilling to acknowledge the manpower cost to provide a comfortable, modem programming environment. Thirdly, insufficient attention has been paid to rationalizing the applications through common code, templates, etc. in order to avoid disjointed programs and duplicated code. An example of such a rationalized approach is the device access package Tm:'-aPS, used at the PS [9] . Furthermore, timing and synchronization and the operational aspects of controls were treated differently from one system at CERN to another. 2. The formation of technical boards The state of diversity at CERN, described in the previous section, was by no way confined to the accelerator control field . Other major technological fields on which the construction of particle accelerators is based, such as power converters, beam instrumentation, radiofrequency, vacuum and mechanical engineering, showed similar differences. Nor was this state of affairs unique to CERN : other laboratories show similar signs, albeit on a smaller scale. This was the natural consequence of the way in which these laboratories had grown, expanding each time a new major construction project was undertaken . These projects, following each other at intervals of several years, each took advantage of the latest technologies and methods, so the variety of equipment installed and still operational at CERN today reflects the progress of technologies over about 30 years . For CERN this was a consequence of the way in which the organization had been managed during the first two decades of its existence . In the first twenty or .orld cvsr CERN _-____ ~-......~ " " "" --- (`AtchJL6+va36a world SO YGÜ , of in terms US laboratories with the leading ing up underlying advanced as the physics as well particle technology. Management was fairly liberal, often allowing several technological approaches to coexist or even to compete, with the aim of stimulating their development. Moreover, funding of nuclear- and particlephysics research was still relatively generous in all major industrial countries of the, world, and CERN had a unique position in Europe. l
the _ACa_E~11116 Z8
.mod
üJSàQ
X. STANDARDIZATION
310
B. Kuiper / Accelerator controls at CERN
During the third decade of CERN's existence, this favourable situation was changing. On one hand, CERN had reached a recognized world leadership in accelerator construction and particle physics . On the other, competition in Europe for public funds for the purpose of pure and applied science had become more intense, while some of the post-war gloss of particle physics was wearing off. In 1986, CERN was working with a level budget and a slowly declining staff, while providing a steadily growing service to the high-energy particlephysics community . This called for a different style. At the same time there was a debate inside the UK physics community, who, seeing most of their shrinking physics funds going to CERN, started questioning their membership in that organization. A consequence of this was the formation of the CERN Review Committee [10] called the Abragam Committee after its chairman, which was given the mandate to review the operation of CERN under the present budgetary conditions and under alternative, reduced budgets. On the technological side, CERN responded to these new challenges by, amongst other things, forming a number of Technical Boards with the mandate to make recommendations for rationalization in the major technological areas, with an eye on possible economies in the use of resources . These boards had no executive authority. The mandate [11] being formulated in extremely broad terms, it remained to the Technical Boards themselves to identify a number of goals with a realistic chance of success in a few years and in the prevailing CERN conditions . Opinions in the controls community varied . Some held that, since practically all the major decisions for LEP had recently been frozen, not very much could be expected by way of convergence until several years after LEP was commissioned . Nonetheless, the time looked propitious for a dispassionate look at our ways and methods, since it would not become subject to the traditional blackmail with delivery times ("either you let me do it my way, or it's your fault that I won't meet the deadlines") . Of course there would be no way of changing the things already under way . Nor would it be possible to make changes in existing installations in the near future, due to the very large investments required. But one could try to get agreement on a number of principles and goals, to which one could converoa eocirig e-erv racnrtaialp nnnnrt__h , . ., .. . ... .~,. ... . ... .. . ...) .e,"..mab .e vrr-tu ....., ___ ac ..... new installations or major rebuilds . With this in mind, two broad goals were set to get people on speaking terms with each other and to set a number of b` key switches to convergence". A first and essential step in the direction of convergence is to have a systematic exchange of experience between engineers and technicians at the working level. Before 1987, such exchange was sporadic, due to the organization by projects and divisions, geographical
separation, and also for purely human reasons . The emphasis on the working level means that involving only group leaders and division leaders would not suffice, so initiating this systematic dialogue between broader layers of controls people should receive the very highest priority. An essential condition for the convergence of methods and collaboration on common objectives is agreement on a reference frame of basic principles and boundary conditions. Until 1987, and even up to now, a number of existing conditions were impeding collaboration on common objectives. These were the different, and mostly incompatible, design options which had been taken early on, either to allow for technological change or through purely human causes. In those circumstances, delivery of the next development would always be faster and cheaper by following existing habits, at least when seen in the narrow local context . On the CERN scale, however, and taken over a number of years, this vicious circle has a price which we are now beginning to understand. The next highest priority was therefore to forge agreement on a sufficient set of basic principles to eliminate, in the medium term, these excuses for incompatibility .
3. Methods, topics In order to organize a systematic dialogue in broader layers of the controls population, the technical board TEBOCO had to be organized appropriately. In consultation with the group leaders for accelerator controls, a number of members were chosen for the board. They had to be open to new ideas, willing to take a CERNwide view and actively contribute to some convergence ; they had to have proven track records in some technical field(s) of accelerator controls, they had to have sufficient seniority, or some executive responsibility such as section leader, and then they should have mature judgement and a way with people. All divisions should be represented fairly . Each member of the board was expected to act as prime mover in one of the chosen fields of action (see below). For that purpose he was required to head a "chapter", a subcommittee of specialists in the field. Cin~rinitialler tr1~PTP ILPYP CPIrPI'~ !`hantrPrc aeraraoina cPVan
members each, this gave an involvement of around 50 specialists out of a total controls population at CERN of between 200 and 300 . This is in agreement with the objective of a broad involvement at the working level. Formal meetings were to be about 2 hours each month . Chapters were allowed to set up working parties for specific goals . The fields of action covered by the chapters and their specific objectives were:
B. Kuiper / Accelerator controls at CERN
Control system architecture : to investigate unifying principles and try to agree on a reference frame for future convergence in methods and for collaboration on common goals; to review proposals of the other chapters on a total-system basis. Specific control electronics : to explore the possibility of common methods and products for future process interfacing and make proposals for a hardware-software kit with an accompanying support service. Operational protocols : to explore the possibility of convergence in high-level access protocols to process equipment and to make proposals for CERN-wide protocols for each category of equipment . Applications software : to explore the possibilities of rationalization of the applications development process and propose common methodologies and common high-level tools . Programming environment : to review the needs for the programming environment and propose a basic but comfortable set of (preferably commercial) packages to provide for those needs and give guidelines on their use . Operational aspects : to review the principles and styles of man-machine interfaces and make suggestions for unifying principles. Timing and synchronization : to survey inter-accelerator timing, with a view to overall coherence and reliability, and suggest improvements and unifying principles. Technology and workshops : this was a joint chapter with the Technical Board for Electronics for Research, TBER. Its objectives were to suggest a CERN-wide approach on CAD/CAE, on the introduction of new electronics technology and on electronics assembly workshops inside CERN . The chapter was soon dissolved, pending reorganization in the research sector. 4. Results 4.1. Control system architecture Surprisingly, progress in this field, which initially seemed to have the strongest historical constraints, was spectacular. The event which opened the door for convergence in system architecture was the collapse, early in 1988, of the LEP contract for a VME-based multiprocessor system (DLX) and its operating system iT 1C`TD E
A A- ;o;nn
then tnI,Pn
t(1
phiO the- onn
by using IBM-compatible PC/AT computers on the token-ring network to control the VME crates containing the MIL/STD-1553 drivers. A few months of reflection yielded a compromise [121 between the controls groups of LEP/SPS on the one hand and that off PS on the other. That compromise involved a choice of open systems, in contrast to proprietary ones. It also involved a stated preference for mature commercial systems over custom- or home-made ones, but not formally excluding
Workstations
Server(s)
PS :
SPS/LEP:
APBLLO VAX UNIX U PS : ULTRIX both : X-Windows DEC-®Vindows
Backbone LAN Bridle Regional LAN
PS . SPS/LEP. Token-Ring Ethernet both : TCP/IP
SiNple Instruwentatiiu
Fig. 1. Simplified hardware architecture for CERN accelerator control . the latter . At the workstation level, PS would drop their former choice of the VMS operating system and would use ULTRIX. In turn, SPS/LEP agreed to move to pure UNIX V in their Apollo workstations, proposing to drop their (partial) dependence on the proprietary Aegis system . Both parties agreed to use XWindows and DEC Windows and would jointly explore possibilities of using other industrial packages, such as DVDraw/DV-Tools etc ., and possibly adapting home-made ones (e.g. the DataViewer from SPS) to Windows. At the process control level, where real time is an issue, both parties agreed to use VME, the Motorola 680XX family of processors and the OS-9 real-time operating system, allowing native software development and cross development. For networking, the emphasis was on the communications protocol, since that governs much of the possible software compatibility . It was agreed to use TCP/IP in both cases, on Token Ring at the SPS/LEP and on Ethernet at the PS. Although the network hardware is different, as is appropriate to the two environments, the common protocol will allow easy communication and opens the door to joint projects and products. The agreed hardware architecture is depicted in fig. 1 and the software architecture is given very schematically in fig. 2. At LEP, and therefore later also at SPS, the VME/MC-680XX/OS-9 combination would replace the present PC/AT, XENIX Systems . At the PS a transition strategy was devised, allowing a migration X. STANDARDIZATION
B. Kuiper / Accelerator controls ai CERN
31 2
that a large majority of specific control electronics could henceforth be synthesized from one judiciously composed hardware and software kit, called the SCELKit . Agreement was also reached on the nature of that kit and of a support service which was proposed by a specially mandated working party [13]. A recommendation was issued to the management to implement the use of this kit and set up the service. It is hoped that this will become effective early next year.
Analysis, Design, Management, Compiler
Application Builder
Test A Diagnostics Builder
Programing Environnent
operating System's
M F S
Task Execution Environment Remote File Access
Data
Du
Viewer
Draw
DEC-Yindows X-Vindows
Primitives
4.4. Operational protocols R P C
TCP/IP Operating System Hardware
Fig. 2. Simplified software architecture for CERN accelerator control.
from the present system to the new CERN architecture . After these decisions were made late in 1988, six joint working parties have started to elaborate the details and have made good progress . 4.2. Programming environment
The options tAen in the field of software architecture mainly determine the programming environment . On the workstation side, this is the UNIX environment with C as a language, and on the process side, the same C language in an OS-9 environment . For the latter there is the native environment and a cross-development possibility from the CERN central facilities. In addition, FORTRAN will be supported for certain applications. The NODAL interpreter will be conserved for troubleshooting and fast prototyping and is being recoded in C. The possibility of using so-called "integrated development environments", such as for ADA, has been reviewed, but a decision must wait for further maturing . One may not have attained the ultimate in comfort, therefore, but in compensation there is clarity, some measure of integration and a considerably reduced diversity for programmers . 4.3. Specific control electronics
In this field, the initial timid hopes have been realized. After a systematic review of the various methods and product choices at the equipment level, and of the various satellite control systems, consensus was reached
The working party for power converters reached a consensus on an operational model which could represent the overwhelming majority of power converters at CERN. A control message derived from that model was then proposed. A detailed document [14] was issued, describing the model and the message . A new kickermagnet system at the SPS will incorporate these protocols and evaluate their practicality. For beam instrumentation, the same exercise was undertaken by a small working team, and a model and a message have been proposed [15]. The opportunity of a rebuild was taken to prototype the proposals on a system of beam transformers for the PS booster. The system is now starting to work [16] and first results are encouraging. Paradoxically, it seems likely that one operational model may satisfy the requirements for the majority of beam instruments. Moreover, the proposed messages for instruments and power converters have the same morphology [17]. The working party for vacuum protocols started their study in the spring of this year, since the vacuum groups of both the PS and the SPS plan to completely refurbish their specific control electronics. This line of development has drawn interest from other laboratories and collaboration on operational protocols is under way with seven European laboratories [18]. This is being organized by members of the working party under the auspices of the EPCS, the European Physical Society's interdivisional group for Experimental Physics Control Systems . 4.5. Application software As a first priority . the chapter concentrated on introducing, for accelerator application development, a methodology for computer-aided software engincer1ng (CASE), as pioneered at ÇERN in the FP and SPS divisions . Consensus was reached on a common software tool package, Teamwork from CADRE [19], and advantageous terms were obtained for CERN and affiliated organizations, as well as for EPS-EPCS-affiliated organizations in Europe . On the initiative of the ORACLE data-base users group for accelerator applications, SQL, *NET was recommended as a standard for access from LEP controls to the LEP ORACLE data
B. Kuiper / Accelerator controls at CERN
base on the VAX cluster . With a view to further rationalization, the chapter is presently engaged in a systematic analysis [201 of certain categories of software packages existing at the three CERN accelerators . These packages represent either application-oriented functionalities (not code) common to several accelerators, or tools for producing specific application software. The study is concentrating on identifying how far these programs, or parts thereof, must depend on the accelerator and/or controls environment in question . The aim is to find programs that could be, or could become, transportable and thereby common to the CERN accelerators. These hopes have been refuelled by the adoption of the common CERN software architecture. Contacts with other laboratories are also being maintained on this theme, under the auspices of EPS-EPCS. 4.6. Timing and synchronization Inter-accelerator timing problems were reviewed and additional diagnostic equipment was specified and is under construction. The 1 kHz timing signal is now being derived from the clock at the SPS and distributed to the PS. A suggestion for a CERN-wide supercycle programming system was thought to be premature. The same date-and-time tagging system for identification of beam instrumentation measurements is now available at all accelerators . 4.7. Operational aspects The operational habits relevant to controls were reviewed and a colour code for displays wa.~ agreed. The use of the industrial software package DV- .`raw/ DVTools was recommended for certain classes of applications such as general services and vacuum . The conversion to workstations at the PS complex will involve substantial rewriting of application software and an operational specifications study has been launched using the combined CERN experience in this field . In particular, an exercise in high-level structuring of process and data will be made, as pioneered at LEP [211. 5. Reflections, discussion -la-_ 1L_ d-_, 1___ aL_ tb__GG_ ., .s: . .- .,.0 mL . . 1 ~Qdy LIli1 Â LIIi yGiliba1LG1 t11%; bâCatiVlt vi tale
less Technical Board, the situation for accelerator con±rols at CERN has changed drastically : (1) c systematic dialogue within the controls population has become a reality and (2) the relevant key switches have been set to allow further convergence . The physical state of the control systems is still very much like that early in 1987, with the exception of LEI', which has meanwhile become operational, with the control system [22] decisively contributing to a smooth
31 3
start-up. Instant unification is of course out of the question because of the massive investment that would be required. However, the change in style and objectives, with respect to earlier CERN working habits, has been dramatic. It is emphasized that only the switches are set and that the process of convergence is only starting. A prolonged, imaginative and above all motivated effort at all levels has to be made in order to transform into a mature and robust structure what is now at best a seedling. Consensus is a very fragile seedling; it tends to decay if not adequately nourished and protected . This places the responsibility squarely on the CERN management; they must make the resources available for consolidation and only they can keep the torch burning by combining encouragement with a firm hand! Although the seedling is fragile at the moment, the potential can hardly be overestimated . One unexpected illustration of that potential came when, upon hearing of the CERN plans, two other laboratories, Sincrotrone Trieste and ESRF Grenoble, spontaneously asked to join the working groups. They have made a contribution which yields a modest but real saving for CERN. If the road now taken is consistently followed, then the savings in the 1990s, compared with CERN's earlier working style, could be counted in tens of millions of Swiss Francs . More than that, the users should be better served and life for the controls people may b, .-come more fascinating : instead of reinventing the same thing in multiple flavours, they will be working on real innovation . To conclude, we give some comments on the experience gained and some conclusions drawn when working together in TEBOCO . Contrary to expectations, the atmosphere at the working level - up to group leader - has been surprisingly positive and constructive from the start. Even persons reputed to go their own way showed a willingness to try a new approach . Many persons have spontaneously joined the working parties and even spent their spare time on elaborating proposals . Middle management - group leaders and division leaders - had more reservations. Obviously, a horizontal coordinating structure making recommendations to the technical director has built-in contradictions with the vertical hierarchy . In addition, a certain percentage e~â nnA the Vl oé~~r$ V " mtim4 cvara$ svaam in$cT~A~~~ mamcv nar+vvv ILAr~C """ + . .~------ real -----
nerg---
centages were the object of some dispute . Some mild friction was relatively frequent, a few skirmishes were fenced out in more detail or were postponed and, of course, the question "who is in charge here?" was repeatedly heard. Top management - the technical director and above - gave their due support in verbal encouragement to the TEBOCO Board and also to the chapters. The technical director spent the time he could afford. At the board }C. STANDARDIZATION
31 4
B. Kuiper / Accelerator controls at CERN
level this was not always felt to be adequate. Indeed, what TEBOCO was mandated to do, stated in caricature, was to disentangle in a few years a jungle which had happily vegetated over two or three decades . This is only possible with very active support from the top . The job has therefore been frustrating at times, but the challenge, and the strong stimulus of the believers, and finally the results, have handsomely compensated for the sufferings. It is our considered opinion that these jobs could be done more efficiently with an executive mandate. Division leaders and group leaders are eminently reasonable and will work together when having an explicit mandate to do so. Last, but not least, it should be said that some of the problems would not tend to appear at all if the controls groups were united into one horizontal controls service. Although some other problems would then certainly arise, in times of insufficient resources that structure seems preferable . For that reason TEBOCO has made a recommendation in favour of an integrated controls setup [23] for all CERN accelerators . Acknowledgements It is a pleasant duty to thank all those persons who, with much good will and enthusiasm, and often in their spare time, have contributed to the rationalizations by placing their experience at the disposal of the others and by working out concrete proposals for convergence. Their names are listed below. - TEBOCO Board : J. Altaber, G. Baribaud, L. Burnod, A. Daneels, B. Kuiper (chairman), M. Rabany, R. Rausch and G. Shering. - Chapter on system architecture : J. Altaber, F. Di Maio, F. Perriollat, M. Rabany, R. Rausch (chairman) and C.-H. Sicard. - Chapter on specific controls electronics : P. Burla, G. Cavallari, E. Ciapala, J . Dieperink, R. Flockhart, A. Guyard-Marigny, W. Heinze, C. Jacot, M. Rabany (chairman), R. Rausch, P. Strubin and A. Swift. - Chapter on operational protocols : R. Bailey, G. Baribaud (chairman), G.P. Benincasa, P. Burla, G. Coudert, G. Gelato, H. Kuhn and R. Saban. - Chapter on application software : P. Andersen, L. Casalegno, J. Cuperus, A. Daneels (chairman), L. Jirden, G. Kellner, R. Keyser, J. Lewis, Ch. Serre and . Tyrrell . Chapter on programming environment : J. Altaber (chairman), P. Andersen, L. Casalegno, N. De MetzNoblat, J. Miles and F. Perriollat. Chapter on timing and synchronization: G. Baribaud, G. Beetham, J. Boillot, .ï. Boucheron, L. Burnod (chairman), G. Daems, R. Lauckner, J. Lewis and J.-P. Riunaud .
Chapter on operational aspects : M. Boutheon, G. Daems, L. Evans, A. Faugier, G. Guignard, V. Hatton, J.-P . Potier and G. Shering (chairman). - Working party on "power converter protocols": J. Bonthond, P. Burla (chairman), G. Coudert, A. Fowler, D. Grier, H. Henrichsen, H. Kuhn, R. Maccaferri, G. Mugnai, R. Pittin, P. Schneckenburger and J.-P . Royer. - Working party on "vacuum protocols": M. Bourgeois, B. Desforges, L. Henny, P. Strubin (chairman), D. Swoboda and G. Baribaud . - Working party on "beam instrumentation protocols" : R. Bailey, G.P. Benincasa (chairman), L. Casalegno and G. Gelato. - Working party on "hardware/software SCEL kit": A. Ball, P. Brummer, A. Chapman-Hatchett, E. Ciapala, G. Coudert, C. Eck, R. Flockhart (chairman), J. Gamble and G. Molinari . Last but not least, our Technical Director, Giorgio Brianti, who instituted the system of technical boards, had to endure various problems, patiently smoothing out numerous minor conflicts which inevitably arise from the inherent contradictions between the vertical executive hierarchy and a horizontal coordination structure. We thank him for his encouragement and for his efforts towards making possible this undertaking. -
References [1] M.C. Crowley-Milling, The Control System for LEP, DGDI/MCCM/tr (17 Nov. 1980) . [2] M.C. Crowley-Milling, The Design of the Control Systcrn for the SPS, CERN 75-20 . [3] G. Baribaud et al., IEEE Trans . Nucl. Sci . NS-26 (1979) 3272. [4] B. Kuiper (for the PS controls Group), IEEE Trans. Nucl. Sci. NS-32 (1985) 2044. [5] P.G. Innocenti, Proc. Europhys. Conf. on Control Systems For Experimental Physics, Villars, 1987, CERN Yellow Report, to be published . [6] J. Altaber, Proc. 13th Int . Conf. on High Energy Accelerators, Novosibirsk, Aug. 1986 (Nauka, Siberian Division, Novosibirsk, 1987) vol . 2, p. 207 . [7] E. Asseo et al., IEEE Trans. Nucl. Sci. NS-26 (1979) 3319. [8] G. Baribaud, P. Burla, A. Daneels and J. Pett, Control Methodology for Accelerator Power Converters, LEPPC/JGP/rl (February 1987). [9] L. Casalegno et al., Proc. 7th IFAC Workshop, Mayschoss/Bad-Nauenahr, Sept./Oct . 1986 (Pergamon Press, 1986) p. 143. [10] A. Abragam et al., Final Report of the CERN Review Committee, CERN 1676 (3 Dec. 1987). [11] G. Brianti, Technical Boards, Terms of Reference, CERN (1986) . [12] J. Altaber, F. Perriollat and R. Rausch, Proposal for Active Collaboration and Convergence between Accelerator Control Systems, SPS internal note (5 Sept. 1988).
B. Kuiper / Accelerator controls at CERN [131 R. Flockhart, Hardware/Software SCEL-KIT for Specific Accelerator Controls Electronics, a report to the SCEL chapter of TEBOCO (rev. Oct. 1989). [141 J. Bonthond et al., Specification for a Control Protocol for Power Converters, PS/CO/WP 88-23 (rev. 2) (draft of 23 Jan. 1989). [151 R. Bailey, G. Benincasa and G. Gelato, Control Protocol for Accelerator Instrumentation: A First Approach, PS/CO/Note 88-24. [161 G. Benincasa et al., Implementation of a Control Protocol in the Instrumentation Field, these Proceedings (Int . Conf . on Accelerator and Large Experimental Physics Control Systems, Vancouver, BC, Canada, 1989) Nucl . Instr . and Meth. A 293 (1990) 338. [171 G. Benincasa, P. Burla and L. Casalegno : Final Convergence of the Power Converters and Instrumentation Control Protocols, PS/CO/WP 88-27 (10 Nov. 1988).
31 5
[181 A. Daneels, Interdivisional Group Experimental Physics Control Systems, Europhys . News 20 (1989) 110. [191 A. Daneels and G. Kellner, these Proceedings (Int . Conf. on Accelerator and Large Experimental Physics Control Systems, Vancouver, BC, Canada, 1989) ',Jucl . Instr . and Meth . A293 (1990) 382. [201 A. Daneels, ibid., p. 325. [211 C. Fisher et al ., Report on the Principles, Contents and Conventions of the Analysis Made by the LEP Applications Analysis Working Group (AAWG), LEP note 597 (22 Dec. 1987) . [221 P.G . Innocenti, The LEP Control System : Architecture, Features and Performance, CERN SPS/89-35(ACC); presented at the Int. Conf . on High Energy Accelerators, Tsukuba, Aug. 1989 . [231 B. Kuiper (for TEBOCO), Abragam and All That, memorandum to G. Brianti (2 Nov. 1987).
X. STANDARDIZATION