Baratange, S

Boccard, C

Bogey, T

Brazier, J C L

Coussemaeker, D

Dach, M

De Vries, J C

Gras, J J

Hiller, H

Jackson, S

Rybalchenko, K

CERN Document Server

REAL-TIME AND CONTROL SOFTWARE FOR THE NEW ORBITMEASUREMENT SYSTEM OF THE CERN SPSJ.C. de Vries, S.Baratange, C.Boccard, T.Bogey, D.Coussemaeker, M.Dach, J.J.Gras, H.Hiller,S.Jackson, K.Rybalchenko, CERN, Geneva, SwitzerlandJ.Brazier, Brazier Systems and Consultants Ltd., Southampton, UKAbstractThe 240 channel SPS Orbit acquisition system isimplemented on PowerPC under the LynxOS operatingsystem, making use of multi threaded real-timecapabilities. The acquired data is transferred efficientlyby DMA on the PCI bus into the main memory. Systemconfiguration aspects were implemented in a Brokerarchitecture, where individual threads communicate withan Oracle database and the acquisition systems. ThisBroker hides the implementation details of the front-endsystems. A versatile configuration client is provided inJava, to provide both local graphical user interfaces andremote WWW access using a dedicated gateway to theSL equipment layer. The timing diagnostics of theacquisition system are provided in a LabView applicationintegrating oscilloscope control and channel multiplexcontrol. This paper describes in detail the technicalsolutions implemented and reports on the argumentswhich have led to particular choices.1 MOTIVATIONWith new technology and new expectations frommachine physicists the replacement of the old orbitsystem (COPOS) was inevitable. With the similarity ofthe trajectory systems (TLPOS) the need for a commonconfiguration strategy (XPOS) was clear. The creation ofthis environment allowed the transparent migration tothe new orbit and trajectory systems (MOPOS).The replacement orbit system not only has the abilityto provide multiple orbits in any point in the cycle butalso allows multiple clients to access the system inparallel. In addition, the high performance hardwareallows real-time calibration of the trajectories forharmonic analysis tools.2 FRONT-END ACQUISITION2.1 General LayoutThe real-time software within the MOPOS system isbased upon the ROCS core software used successfully inother systems within the SL Division at CERN. This hasbeen more fully described in [1]. The ROCS software is ageneralised framework for creating event driven, semi-hard real-time applications. The system allowsautonomous real time control of the acquisitionhardware, and at the same time allows background dataconversation to take place. Additionally, user commands(which enter via network ‘Equip’ calls) are also executedin parallel.The software consists of three sections viz. Userinterface and control modules, timing and sequencingmodules and acquisition hardware control modulesThese modules consist of a number of processes andthreads connected together with Inter ProcessCommunication Links (IPC) and using Shared Memorystructures to hold the data. These are all written in C andrun on top of the LynxOS operating system. LynxOS is aUnix-like RTOS which runs on the CES RIO2 PowerPCprocessor.The User Interface consists of three separate modules,namely• The ‘Equip Server’ which receives commandsfrom the rest of the system via an RPC basedEquip call and passes any data back.• The command processor ‘rocsfe’ packages thecommand into an Action Structure, tagged withthe special event Now.• The Socket Server module ‘sockmod’ provides analternative, high speed TCP channel with whichto pass large amounts of data back.The heart of the system is the sequencer and actiontasks. This is a multi-threaded program which, on anevent, examines a queue of actions and spawns a threadto carry out the action. There are two types of actions:User where the action is performed once and thendiscarded and Real-time where the action is left on thequeue to be repeated. Examples of real-time actions inMOPOS are those carried out at ‘Beam-in’ and Beam-out’ which start and stop the acquisition logic. Thecommunication between the action code and the sub-systems is done with messages sent to the appropriatemodules. Some actions, such as background tasks thatfilter the raw acquisition data, result in new processesbeing created.The timing module drives the sequencer byinterpreting the machine timing events (received with theTG8 timing card) and generating a stream of logicalevent messages.System tables in the form of the per crate, per channeland per event parameters along with the calibration dataare kept in a shared memory area with access routinessuch that they may be used by any part of the system.International Conference on Accelerator and Large Experimental Physics Control Systems514International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, ItalyStatic versions of these tables are held on a specialbattery backed, non-volatile memory board.2.2 DMAA warning event associated with each elementary cycleinvokes a real-time task which configures the driver ofthe MOPOS acquisition controller interface (MACI).This programs the PCI bus controllers (PLX9080) totransfer the acquisition data from the FIFO memory intosystem memory. The driver interrupt service routine re-programs the bus controller when data transfer exceeds 8MB. Important system specifications include:• Processor PowerPC 604e/400 MHz(CES RIO2 8062)• PMC slots: 6 (CES PEB 6400)• Data Rate 8 MB/s• Acquisition Memory 224 MB• Beam data capacity 28 seconds.• Acquisition channels 40 times 2.Dedicated drivers have been developed for the MACI,the trigger module and the input/output module.3 CONFIGURING MOPOSIn creating a suitable strategy for MOPOS, manychoices had to be made. The chosen strategy should becomplex enough to empower users with the facilities theyrequire, but at the same time it should be comprehensibleto non-computer experts. In addition, the choice ofpossible techniques and tools grows each year, hence thechoice of implementation strategy also requires carefulconsideration.On analysis of the data requirements, it becameevident that the data would fall into two categories:Direct data: This type of data remains constantregardless of the state of the accelerator. An example ofdirect data is the configuration of detectors.Indirect data: This data changes depending on thedefinition of the current running supercycle. Anexample of such data, is event data which changesaccording to factors such as timing.As well as data organization, it was envisaged that thenew configuration system should be designed toeventually incorporate the configuration of other beammeasurement systems (from the transfer lines). Althoughthe configuration of these other systems differs fromMOPOS, many of the same characteristics are shared.Consequently the choice of an object- oriented databaseinitially appeared to be the natural solution. Closerexamination of the indirect data however, revealed that arelational database would be more suitable. As acompromise, a relational database (Oracle 7) was chosenas a basis for data storage, and object oriented techniqueswhere used in its design.Having chosen the basis for storing configuration data,a strategy for database population was required.Proprietary tools supplied by Oracle offered the easiestsolution and quickest development time. However theselacked the features offered by the legacy text-basedconfiguration tools used in COPOS - platformindependence (Oracle 8 now provides 'web' deploymentfacilities, but at the time this was not available). It wasdecided that this platform independence should be keptand as a result, Java was chosen as a developmentplatform for in-house solutions. The choice of Java wasfurther reinforced with its ability to be deployed on theweb, and therefore be accessible by the expert fromhome.A two-tier development process was therefore pursued,with Oracle Forms as the basis for rapid development forthe system developers, and a Java application/applet asthe basis for operators and end-users.4 CONFIGURATION CLIENT / SERVERWith the issue of development environment resolved,the problem of controlled database access was assessed.Tests using the Java DataBase Connectivity (JDBC)package proved this solution would be adequate forcommunications between the client and database, but anadditional factor had to be considered. Although themain access to data would be through the configurationclient, other operational software would also requireaccess to the data. If all data access mechanisms werewritten in Java, this would require existing operationalsoftware to be re-written in Java. This was definitely notacceptable and so the concept of the configuration brokerwas conceived.The broker provides services to clients for databasetransactions. In addition, the broker also provides actionsfor data transfer to and from the hardware. The brokerDetectorDataCalibrationDataEventDataMOPOS CrateDetectorDefinitionsEventDefinitionsSupercycleDefinitionsCalibrationDefinitionsCurrent EventDefinitionsBrokerOps SoftwareJava ClientOracle515mechanism not only provides services, but makes therequest for these services as transparent as possible.Furthermore, clients may continue execution whilst thebroker carries out actions. When both the client andbroker are ready the transaction is completed. Anexample dialogue between client and broker is as follows:• Client requests service from broker.• 'class' and location of target system assessed.• Broker begins execution of 'class' dependant codeand returns a request ID (RID) to client.• Client free whilst request is being handled.• Client asks broker for results using RID.The broker is implemented using three threads underC++ in order to achieve good performance and 'class'transparency. Each thread has a designated task - Oracleaccess, equipment access, and server access. Duringexecution of a service, the broker decides whichoperations are required, and instructs the relevant threadto perform its task. This allows the server to performseveral actions in parallel, thus further enhancingperformance.With the creation of a broker layer, the functionalityrequired from the Java client is reduced to a userinterface which allows the user to request services andview the results. Currently, services available from theJava client include configuration of all MOPOS data,diagnostics, news, tuning, calibration and facilities tointerrogate and change the current status of hardware.The deployment of the configuration client as anapplet, offers great flexibility in terms of accessibility,but also introduces a new problem of security. To addressthis, all users must acquire a token (by supplying a userID and password) from an intermediate gateway(operating from a Linux machine) before communicationwith the broker may take place. In addition, a record ofall client activity is stored in the database.EXTENDING THE CLIENTAfter the success of the Java client, the incorporationof other clients was also considered. An application usedto display positional data was one such application. Inorder to maintain the initial design concepts, anintermediate server, was developed between theequipment and the Java client. This time, the client wasa subscription driven acquisition server. The role of theJava client in this case was to provide facilities to plot theacquired data using third party graph classes from theKL group.5 MULTI-TURN ANALYSISMulti turn applications require many seconds ofcalibrated turn by turn trajectories resulting inmegabytes of data to be transferred. To obtain efficienttransfer and avoid size limitations in buffer orientedprotocols (SL-EQUIP), a TCP/IP socket was usedinstead. The data is transferred via a set of pipes from theacquisition memory to an external process and then sentto the socket server. Many such external processes can becreated to supply user specific data processing.6 DIAGNOSTICS TOOLSAcquisition timing diagnostics have been provided bythe installation of dedicated low-cost oscilloscopes(Tektronix TDS210) and multiplex modules. TheLabView VI for the TDS210 from National Instrumentswas extended to include the multiplex control andsettings handling via XPOS configuration.7 CONCLUSIONThe ROCS system provided the crucial structure tohandle beam-synchronous tasks, handle communicationchannels and provide remote diagnostics.Using DMA for data transfer into the system memory,has provided an efficient means of acquiring the largeamounts of data required. As a result of using DMA theprocessor power can now be utilized to server userrequests and provide calibrated orbits.The chosen configuration strategy achieves its goal toprovide an extendable and manageable means of storingconfiguration data. It hides the implementation details,and provides clients with services for different ‘classes’of systems. The decision to use Java to implement clients,has allowed home access for experts through the WWW,and the use of the applications on many platforms. Dueto the object-oriented nature of Java, sub-components ofthe configuration client can be called as stand-aloneapplications.Successful experimentation with new plottingpackages supplied by the KL group, showed that the useof Java as a serious data analysis platform was feasible.REFERENCES[1] A.H.Dinius et all, “Evolution in controls methodsfor the SPS power Converters, ICALEPCS’95,Chicago, November 1995.516

Real-Time and Control Software for the New Orbit Measurement System of the CERN SPS

Real-Time and Control Software for the New Orbit Measurement System of the CERN SPS

Abstract

Similar works

Full text

Available Versions

CERN Document Server