The workstations used within the control system of the CERN PS accelerator complex are not produced any more. We had therefore to review the software primary used as user interface and we achieved a port to IBM workstations. We are also preparing the maintenance of this code for the next ten years with minimal staff. This implies a clear separation between general computing facilities, control system developments, and operation. In order to share our experience, we will try to summarize various aspects of this migration: - system installation principles used to speed-up error recovery time and long-term maintenance costs, - problems correlated with the coexistence of two different platforms during migration, - software problems due to the platform and operating system changes, - hidden dependencies from a specific manufacturer

De Metz-Noblat, N

Metz-Noblat, de N

CERN Document Server

Migrating the cern ps control system to ibm workstations

MIGRATING THE CERN PS CONTROL SYSTEM TO IBMWORKSTATIONSNicolas de METZ-NOBLATPS Division, CERN, CH-1211 Geneva 23, SwitzerlandABSTRACTThe workstations used within the control system of the CERN PS accelerator complex are not produced any more.We had therefore to review the software primary used as user interface and we achieved a port to IBM  workstations.We are also preparing the maintenance of this code for the next ten years with minimal staff. This implies a clearseparation between general computing facilities, control system developments, and operation.In order to share our experience, we will try to summarize various aspects of this migration:• system installation principles used to speed-up error recovery time and long-term maintenance costs,• problems correlated with the coexistence of two different platforms during migration,• software problems due to the platform and operating system changes,• hidden dependencies from a specific manufacturer.1.  INTRODUCTIONDuring the five last years, the PS Division has realized a large work to renew the control system of the CERN PSparticle accelerator complex [Ref. 1 & 2].This resulted in the introduction of a rather large number of UNIX workstations and X-terminals mainly used for thedaily operation and the exploitation of the CERN PS complex.Our primary choice was for DEC  workstations based on the 32 bits MIPS microprocessors. The new generation ofDEC workstations is based on a new 64 bits chip and a new operating system. The amount of work required to portour control software to this new generation was almost the same as the one that would have been necessary to port itto any other UNIX workstation. After detail cost analysis, we decided for the IBM RS/6000 workstations based onthe PowerPC  chips, and running AIX system.The introduction of a new generation of workstations is also a good time to review organization details in order tominimize the staff required for the long-term maintenance of such computing resources.2.  NETWORK TOPOLOGY [Fig. 1]We have been introducing a large number of workstations (>100) and diskless front-end computers (>100), initiallyto develop a new control system and then to operate and maintain it. The problem was to keep this maintainable.We did split equipment into two different networks isolated by a router:• An office network: This receives development and test equipment, and can support longer intervention delays.• A control network: This concentrates equipment needed for normal operation of the complex.Then we did then split this control network into various subnets, isolated today by bridges:• a central control subnet on which we keep some critical services like central timing generator or databases,• one subnet for each accelerator (or group of accelerators):• one for the proton and the ions LINACs,• one for the LEP Pre-Injector complex (LIL and EPA),• one for the PS Booster (PSB),• one for the CERN Proton-Synchrotron itself and its transfer lines (CPS).We organized each subnet to still allow a minimum operation from a local control room, even when disconnectedfrom the central control subnet. Diskless computers rely only on a single file server located on the same subnet torecover after a power-cut.bridgeDSC DSC DSCbridgeDSC DSC DSCbridgeDSC DSC DSCbridgeDSC DSC DSCDSC DSC DSCDSC DSC DSCLPILINAC 2&3PSBCPSSL/control network PS/control networkCERN/public networkSL FDDI backboneCERN FDDI backbone networkLEARISOLDEPS offices and testsbridgebridgeRouterDSC DSC DSCDSC DSC DSCDSC DSC DSCNovell serverVMS serverUnix serversLocal serversPCsUnix workstationsPCsMeyrin Control Roomand central services(Central Timing, SOS).Local serverLocal serverLocal serverLocal serverLocal control roomstations & acceleratorspecific front-endsCommon PS/SL databaseFig 1: The network topology3.  FILE SYSTEMS ORGANIZATIONWe had to decide early for a well-structured file organization that could stay stable during the whole project.We decided the following organization:• One file system per accelerator: This receives all programs required for the minimum operation and all softwarespecific to this accelerator, including software running in diskless front-ends.• One file system for central services: This receives programs that are not critical for the minimum operation andused for the control of more than one accelerator..• One file system for control software source's repository: this receives sources of all programs developed for thepurpose of the accelerator control. Its structure reflects the target file systems in order to ease long-term softwaremaintenance.• One file system to receive libraries and associated include files for each different target. This file system receivesalso specific programs required either to produce the applications, or to maintain operational data.• One file system to receive Word-Wide Web documentation used for on-line help.CERN central computing service furnishes other resources not used for normal operation:• Home directories can be located on central servers,• Public domain software must stay maintained centrally,• Whenever possible, commercial products have to stay also centrally maintained.4.  MIGRATION STRATEGYBefore deciding for new UNIX workstations, we did a preliminary inventory of all our software and our dependenceon specific features. Nearly 30 different programmers did already develop  around 100 applications. Then, we did porta significant application to various platforms and evaluated constraints.The next step was to start the porting with a small number of workstations and servers in order to prepare avalidation of almost all applications in a real context co-existing with the current environment [Ref. 3].We had to minimize required staff and interference with still going-on developments and normal beam production.We prepared an independent environment to receive sources and libraries, and a clone of existing operational filesystems. This allowed us to prepare final software distributions and to execute applications in a realisticenvironment, keeping the same data source database for software customizations like program menus and equipmentlists.The next step (March 1996) will inverse the situation between old and new workstations in order to avoid thesimultaneous maintenance of two binaries for the same applications.The last step will be to reduce the platform diversity in order to reduce system management complexity and to easenew application development.5.  PROBLEMS ENCOUNTERED DURING THE MIGRATIONDeveloping our applications, we tried to avoid the use of manufacturer specific extensions to standards, and themigration was a good occasion to verify this point.We did not encounter any major problem while porting almost all the software to the new platform.Some problems were coming from libraries updates of like standard Motif and X11, or from our own libraries. Witha new development environment on both platforms, it was possible to isolate and clean these problems.The second kinds of problems were due to dependencies from the environment:• Some programs were using specific fonts.• Simultaneous usage of various UNIX variant's compatibility routines (Berkeley Software Distribution, System Vand POSIX) does not mix always properly.• Our front-ends already had a different byte order and most programs were already ready for such a change.• C compilers and system include files differ, but without any major incompatibility.• We tried to avoid as most as possible the use of Display Postscript extension, except for two applications.• One application was using a specific external video input extension and multimedia libraries. We will need toadapt it and hope that -- with current developments in the multimedia area -- some standards will be available forthis field.The migration itself was an occasion to locate small programming mistakes, or surprising limitations introduced bythe programmer. A typical example was the limitation to six characters of a host name!We had to prepare also the future development environment: for example, we had to decide for a new User InterfaceBuilder program.6 OTHERS SYSTEM CONSIDERATIONSWe try to prepare long-term exploitation solutions:• We try to use the same system installation procedures than other CERN central UNIX services with minimumspecific customizations, in order to share experience and support.• We prepare all critical computers for a remote exploitation. This applies to servers and to front-ends.• Our network layout is clean, easy to understand, and is organized to allow longer intervention delays on non-critical equipment.• We keep coherent contents within file systems, and with automated backups.7.  CONCLUSIONThis exercise of porting our control software was very positive. It was an occasion to evaluate in details ourdependencies, and to check its completeness.This demonstrated the interest of an UNIX to maintain of a large amount of software written in the C language.However, it is very important to choose emerging standards and to avoid any specific extensions to these.We expect to reach during next year a very clean and stable situation with work-stations, servers, and controlapplication software. That might open us to some out-sourcing solutions as we already experienced with the systemmanagement of the LEAR control system.ACKNOWLEDGMENTSI would like to thank Michel Arruat, Franck di Maio, Serguei Moukhine, Orel Oleg and Fabien Perriollat for theirgreat help to achieve this work in the planned delays. I would like also to thanks all applications developers for theircollaboration and the various people who have been testing the resulting environment.REFERENCES[1] F.Perriollat, Ch.Serre, “The new CERN PS control system, Overview and status”, ICALEPCS, Berlin,Germany, October 18-23, 1993, Nucl. Instr. And Meth. A352 (1994) 86.[2] R.Rausch, Ch.Serre (editors), "Common Control System for the CERN Accelerators", ProceedingsICALEPCS, Tsukuba, Japan, 11-15 November 1991, p.54-58The PS and SL controls groups, "PS/SL Controls Consolidation Project", Technical Report, CERN PS/91-09(CO), CERN SL/91-12(CO), April 91.[3] M.Boutheon, F.DiMaio, A.Pace, "General Man-Machine Interface used in Accelerator Controls; SomeApplications in CERN-PS Control System Rejuvenation", Proceedings ICALEPCS, Tsukuba, Japan, 11-15November 1991, p.452-455

Migrating the CERN PS control system to IBM workstations

Abstract

Similar works

Full text

Available Versions

CERN Document Server

CERN Document Server