Charrue, P

CERN Document Server

The SPS-2001 Software ProjectPierre Charrue, Bernard Denis,Michel Jonker, Marc Vanden Eynden,CERN, Geneva, SwitzerlandAbstractIn December 1996, it has been decided to set up aproject [1] to reengineer the SPS application software toallow efficient operation and to cover the specific needsof the SPS as LHC injector. This presentation reviews thereasons why this project was launched and its scope andobjectives. The project plan will present the OO methodsand the phase decomposition to reach the first importantdeadline in June 2001.The first results of the analysisphase and their implications on the application software,on the controls infrastructure and on the equipmentgroups equipment will be presented.1.  MANDATE OF THE SPS-2001PROJECTThe application software used today to control the SPSis the result of 20 years of evolution of the acceleratorand computer technology. Many application have beendesigned for and by equipment specialists. Although partsof the application software are much appreciated by theoperators, today software does not allow an efficientexploitation of the SPS machine. Since the SPS willprobably run for another 20 years, it has been decided toset up a project to do the re-engineering of the SPSapplication software to allow more efficient operation andto cover the need for the LHC era, that is the usage of theSPS as LHC injector.1.1 Purpose.The purpose of the project is to provide an applicationsoftware suite to operate the SPS and its transfer lines inthe LHC era that is allowing LHC filling, fixed targetoperation and MD's. An important benefit of this projectis to provide an homogenous software suite to the controlroom.1.2 Scope.The mandate of the SPS-2001 project consists of:1. the definition of the strategy to operate SPS in2001 onwards,2. the definition of the strategy to implement the newsoftware,3. the production of all the software that will be usedby the operation crew to operate SPS in 2001onwards.In order to provide an homogenous solution to thecontrol room, the SPS-2001 project will:1. specify the interface to all equipment that must beaccessed for the operation of SPS,2. define the standard services that these equipmentshould provide,3. define a standard Man Machine Interface,4. specify general purpose services and theirinterfaces needed to build the SPS-2001 software;e.g. Data Management Service, Alarm Service,etc. ,5. define a certification principle for (1), (2) and (3).The SPS-2001 project will establish a communicationpath with the equipment groups and other entities thatmight be affected by the project. In addition, it willcommunicate SPS-2001 specific needs and requirementsto other relevant projects such as the PS/SL ControlsConvergence Project and its sub-projects (i.e. Java API,Middleware, Timing Convergence, etc.)The SPS-2001 project is not responsible for:1. the specialist software needed by equipmentgroups,2. the definitions and implementation of the controlssystem infrastructure.1.3 Constraints and Interfaces.According to the number of services required by theSPS-2001 project (i.e. Alarms, DBMS services,…) it ismandatory to clarify, once the requirements are defined,which of these services will be part of the scope of theSPS-2001 project and which will be handled by externalprojects or initiatives. Responsibilities, communicationprocedures and interfaces shall be defined for each ofthese services.1.4 Objectives.The SPS-2001 project will provide:1. the strategy to operate SPS in 2001 onwards,2. the strategy to implement the new software,3. the SPS-2001 certification document,4. guidelines to produce equipment services aswell as application software,5. a first working version of the application suitein June 2001,6. a complete final version in July 2003.Chamonix IX152The SPS-2001 project will organize periodicinformation meetings with equipment groups and otherentities to present the project and its last developmentsand to ensure a good synchronization between the SPS-2001 project and the other initiatives taken in the scope ofthe SLI project.2  THE LHC REQUIREMENTSThe LHC machine has specific requirements on theSPS operation that are driving the SPS-2001 project.These are Fast and flexible cycle change, high machineavailability and new operational concepts.The most obvious one is what is called the Fast andFlexible cycle change. Changing from one cycle orsupercycle to another is possible today in the SPS but thistakes a non negligible amount of time. The future SPSsoftware should provide some facilities that will allow thechange of cycle in a much more flexible and rapid way.This will allow a high machine availability and switchingfrom LHC filling to fixed target physics will be donesmoothly and rapidly. But this implies that equipmentshould not anymore include assumption about the supercycle structure and also that they need to be able tomanage resident cycles and that new functions has to beimplemented in cycle dependant equipment (such as load,unload, activate, …).Switching from one mode of operation to anotherrequires a new equipment surveillance to ensure thatequipment are in the desired state for future modechanges. Subscription mechanisms would give the futuresoftware efficiency and flexibility.3. RELATION WITH OTHERPROJECTSThe SLI project [2] is providing all LHC requirementsthat should be taken into account by the SPS-2001project. One member of the SPS-2001 project is alsomember of the SLI project and the SLI project leader isconsidered as one of the sponsor of the SPS-2001 project.The SPS-2001 is responsible of the SPS operationalsoftware but it relies heavily on other controls projectsthat are defining the Controls Infrastructure of the comingyears. These projects are organized in the so-called PS/SLconvergence project [3].3.1 The PS/SL convergence projectIn December 1996, a memorandum [4] from the CERNdirector of Accelerators expressed the view of theAccelerator Board on the present status and medium-termfuture of the Controls Groups in the Accelerator Sector.The convergence of the PS and SL systems wasrelaunched in 1997 and triggered by a directive from thePS and SL Divisions [5] to investigate and proposeconcrete actions. An Audit on the PS and SL controlsystems has been made by an outside controls expert(C.W.Watson from TJNAF). The result of this auditopened the way towards a PS and SL convergence projectaimed at providing a common controls infrastructure,including support and maintenance, to both PS and SLdivisions.Several sub-projects are now running and the SPS-2001 is relying on the following:3.2 The JAVA API projectThis project is responsible for defining a standardaccelerator device model and then to build a JavaApplication Interface (API) deploying this model. A firstversion of the model is now available [6] as well as a firstJAVA implementation actually used for some ADapplications [7]3.3 The middleware projectThis project is responsible for providing a SoftwareCommunication Architecture and services allowing inter-objects communication and supporting, as first priority,the CERN Java API Technical Specification, includingthe Standard Accelerator Device Model [8].3.4 The timing projectThis project is responsible for building a reciprocalunderstanding of the two timing systems, of maximizingthe sharing of the analysis, design and implementation oftiming hardware, firmware and software components andof providing the new central timing facility required tooperate the CERN accelerator complex in the LHC era[9].3.5  Graphical  representation153Chamonix IX4. WHAT WILL CHANGE4.1 New Sequence Concept4.1.1 Beam-processA beam-process is a specific manipulation of the beamwithin the context of an accelerator cycle. Examples ofbeam-processes are transfer, injection, capture/bunch,debunch, cooling, acceleration, deceleration, store,extraction, dump, etc. Beam-processes are usually limitedin space (transfer zone, ring) and/or time (injection,acceleration, extraction). However, this does not excludethat beam-processes may overlap both in time and spacewithin a given cycle. In terms of accelerator control itmay have particular interest to differentiate the beam-processes in a cycle when there exist independent controlparameter. (e.g. transfer line settings, extraction bumps).A beam-process is defined by its characteristics. Themajor ones are the location (i.e. the parts of the machineinvolved), the time-extend and the set of associated beamcontrol parameters. Furthermore, one can usually defineexplicit and independent performance indicators to beam-processes. (e.g. transmission, emittance blow-up).4.1.2 CycleA Cycle is a predefined set of beam-processes totransport (and transform) beam from source todestination. These beam-processes can have a predefinedfixed length or they can have an undetermined length(accumulation, storage). The number of beam-processesin an accelerator cycle does not have to be predefinedeither; an example is multiple injection for beamaccumulation. The evolution of one beam-process to thenext in a Cycle can be predetermined, or under control ofan external process (control-sequencer or operator). Theparameters of a Cycle can be prescribed or adaptable (i.e.in final energy, extraction intensities). In the case of thepresent SPS control system, the cycle parameters areprescribed, and the evolution of the beam-processes ispredetermined. The only exception, where the beam-process evolution is not predetermined, is in case the SPSis put into coast.4.1.3 Cycle vs. beam-processEach beam-process has a set of associated equipmentto control the beam-process. However, several beam-processes can share the same equipment even at the sametime during a cycle. At present, in the SPS, the equipmentfunctions that are loaded in the hardware and that controlthe beam, are defined on a cycle basis rather than on thebasis of individual beam-processes. In fact, the concept ofbeam-processes has not a firmly defined foundation in thepresent SPS control software. In the future, virtualequipment control channels (i.e. channels acting on thesame equipment but controlled by independent functionsand timing events), may make it possible that certainbeam-processes could be implemented with their ownassociated equipment functions.4.1.4 SequenceA sequence is a predefined group of cycles. Anaccelerator can be multi-cycling with several cyclesexecuted in a sequence. The sequence of cycles can be afixed repetitive pattern (super cycle) or a more flexiblesequence of cycles adapting to the status of the users andequipment. To speed up sequence switching, severalsequences may be resident in the equipment, andexecutable under control of the timing system. The beamscheduling system will respond appropriately to changinginterlock and request conditions in order to select thesequence that makes best use of the available resources.One should further note that a given cycle could bepresent in more than one sequence.For the case where the evolution of beam-processes ispredetermined, it is useful to make the followingrefinement in the definitions of sequences:Predefined SequenceThe predefined sequences are the sequences that areknown to the control system as legitimate combinationsof cycles.Resident SequenceA sequence is resident if all constituting cycles andcycle linkage parameters are resident. A cycle is residentif all the required equipment settings are resident in thehardware and the cycle is ready for execution.Active SequenceThe active sequence is the sequence that is currentlyactive in the machine.4.2 Simple view of the new operating strategy1.Before each period (TBD) physicists and OP crewdefine the physics program of the next period (TBD).This physics program will allow Users to issue BeamRequests.    2.All the corresponding sequences that should beused to handle this physics program are selected from thesequence database and the sequence settings are maderesident in the SPS equipment.    3.Then, depending on the user and operatorsrequests and the possible machine state, the activesequence is chosen within the resident sequencesdepending on the priorities of the client requests andoperators veto. NOTE: This choice of the active sequencecan be made via human intervention or automatic.    4.The central timing system is now directing thescene by "playing" the active sequence in loop untilanother sequence is chosen.    5.NOTE: The equipment themselves are not awareof which sequence is running. They have been loadedwith the settings corresponding to the possible Cycles thatcould be run. The local timing system will warn them thatChamonix IX154the Cycle x will be played soon and then send all thetiming events/telegrams for the running Cycle    6.During operation, things may change either in theuser or operators requests or in the current machine state(for example due to interlocks). Therefore, the activesequence may well not be relevant anymore and then anew active sequence will be selected as explained in 3above.4.3 SPS-2001 Equipment InterfaceThe SPS-2001 project proposes to define a standardequipment interface that will be deployed on top of theproposed architecture given by the middleware project.This standard interface will be defined in conjunctionwith the equipment groups and the operation crew andwill be the base of the SPS-2001 application software. Itwill define services that equipment can provide and alsoservices that operation would like to see provided by theequipment. These services will be classified into groupsof services, such as identification, global statusinformation, state management, cycle management, Cycleparameters, cycle functions, measurement parameters orinformation subscription.The definition and implementation of this standardequipment interface is one of the next important task ofthe SPS-2001 project. It is expected to have a first versionof the definition by June 1999 with some prototypingactivities until December 1999 and the finalimplementation for June 2001.4.4 Standard Man Machine InterfaceAnother piece of standardization that the SPS-2001project would like to perform is the definition of astandard Man Machine Interface. This MMI will offer tothe operation crew a standard environment and thereforean homogeneous view of the SPS operation. Thedefinition and the implementation of this standard MMIwill be carried out in the next months in closecollaboration with the Operational teams.5. THE APPLICATION SOFTWAREThe application software represents all what is betweenthe MMI and the equipment interface and represents thebiggest part of the SPS-2001 project. An Object OrientedAnalysis and Design phase is currently under way [10] todefine and then implement these applications.The purpose of the Analysis phase is to provide acomplete, consistent, readable, and reviewabledescription of the software needed to operate the SPSaccelerator in the LHC era.The objectives of the Analysis exercise are to describethe functions the future SPS software will perform and tostate what kind of performance and resources arerequired.The scope of the analysis will cover all behaviouralaspects of the future software, not its form. Issues relatedto software component design and implementation willnot be pursued during this phase.The actions required to reach the objectives of the SPS2001 analysis phase will be organized around two mainideas, the identification of the functions the future systemhas to provide and the analysis of the behaviour of thesystem for each function.4.4.1 Identifying System FunctionsThis activity will focus on the identification - from therequirements point of view - of the functions the futuresystem has to provide. We consider functions as theexpression of the need rather than the expression ofsolutions. The aim of expressing the need through itsfunctions is to find a better way to breakdown the conceptand to clarify the perception of the problem. Onceidentified, the functions are then clustered according tohierarchies.4.4.2 Behaviour AnalysisThis key activity of the analysis phase will concentrateon running practical scenarios for each function of thesystem. These scenarios will help to find the entities thefuture software will be composed of.  Next, the relationsbetween these entities and the services they provide willbe studied in greater detail. Initiators of these scenarios(ie. operators, external triggers) and contributors (ie.external service providers) will also be identified duringthis behavioural analysis phase. This identification willhelp, amongst other things, to specify interfaces withexternal hardware or software system required to run theSPS as LHC injector.Analysis will be successfully complete when scenariosfor all fundamental (central to the application's purpose)system behaviours will have been developed andvalidated by the experts in accelerator operations andpeople responsible for the external systems that willinterface with the future SPS software.155Chamonix IX6. CONCLUSIONSThe SPS-2001 software project is an ambitious projectto handle the new LHC requirements for the SPS as LHCinjector and also to provide a coherent applicationsoftware suite to operate the SPS. This task could not bemade possible without an attentive analysis of the needs.But neither would it be possible without a goodseparation of responsibilities between all the partiesinvolved. The definition of standard equipment access aswell as standard Man Machine Interface will ease themain task of writing the application software.Finally, this project must be seen as a divisional effortin the SL division and the collaboration of all equipmentgroups as well as the operation crew is essential.REFERENCES[1] The SPS-2001 project - Web sitehttp://venice.cern.ch/~slaps/hot/sps_lhc/intro.html[2] The SLI project - Web sitehttp://nicewww.cern.ch/sl/sli/Sli.html[3] The PS/SL convergence project - Web sitehttp://hpslweb.cern.ch/pssl[4] Mandate for COM K.Hubner AC/KH/dl 96-83[5] Collaboration of PS and SL Controls Groups K.H.Kissler, D.J. Simon CERN MemorandumPS/DI/Memo 97-37 - SL/DI/Memo 97-23[6] Java Controls API Technical Specification -PS/CO/Note 98-16 - P. Charrue, J. Cuperus, I.Deloose, F. Di Maio, K. Kostro, M. Vanden Eynden,W. Watson - 11 August 1998[7] The Java API - Web sitehttp://hpslweb/pssl/projects/javapi/javapi.html[8] The middleware project - Web sitehttp://hpslweb/pssl/projects/middleware/middleware.html[9] The timing project - Web site -http://hpslweb/pssl/projects/timing/timing.html[10]The Analysis Phase Plan of the SPS-2001 project -http://venice/~slaps/hot/sps_lhc/docs/docs.hmlChamonix IX156

SPS2001 Software Project

Abstract

Similar works

Full text

Available Versions

CERN Document Server