The 240 channel SPS Orbit acquisition system is implemented on a PowerPC under the LynxOS operating system, making use of multi threaded real-time capabilities. The acquired data is transferred efficiently by DMA via the PCI bus into the main memory. System configuration aspects were implemented in a Broker architecture, where individual threads communicate with an Oracle database and the acquisition systems. This Broker hides the implementation details of the front-end systems. A versatile configuration client is provided in Java, to provide both local graphical user interfaces and remote WWW access using a dedicated gateway to the SL equipment layer. The timing diagnostics of the acquisition system are provided in a LabView application integrating oscilloscope control and channel multiplex control. This paper describes in detail the technical solutions implemented and reports on the arguments, which have led to particular choices

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

EUROPEAN ORGANIZATION FOR NUCLEAR RESEARCHCERN    SL DIVISIONGeneva, SwitzerlandNovember, 1999CERN SL-99-069  BIREAL TIME- AND CONTROL SOFTWARE FOR THE NEWORBIT MEASUREMENT SYSTEM FOR 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, Switzerland.J. Brazier, Brazier Systems and Consultants Ltd., Southampton, UK.AbstractThe 240 channel SPS Orbit acquisition system is implemented on a PowerPC underthe LynxOS operating system, making use of multi threaded real-time capabilities. Theacquired data is transferred efficiently by DMA via the PCI bus into the main memory.System configuration aspects were implemented in a Broker architecture, whereindividual threads communicate with an Oracle database and the acquisition systems.This Broker hides the implementation details of the front-end systems. A versatileconfiguration client is provided in Java, to provide both local graphical user interfacesand remote WWW access using a dedicated gateway to the SL equipment layer. Thetiming diagnostics of the acquisition system are provided in a LabView applicationintegrating oscilloscope control and channel multiplex control. This paper describes indetail the technical solutions implemented and reports on the arguments, which have ledto particular choices.Presented at ICALEPS’99International Conference on Accelerator and Large Experimental PhysicsTrieste, Italy4-8 OctoberInternational conference on accelerator and large experimental physics control systems (ICALEPCS)4-8 October 1999, Stazione Marittima, Trieste, Italy1REAL TIME- AND CONTROL SOFTWARE FOR THE NEW ORBITMEASUREMENT SYSTEM FOR 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 a PowerPC under the LynxOS operatingsystem, making use of multi threaded real-timecapabilities. The acquired data is transferred efficientlyby DMA via 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 arguments,which have led to particular choices.1   MOTIVATIONWith old components becoming obsolete, newtechnologies available and new demands for functionality(like turn by turn measurements) the replacement of theold orbit system (COPOS) was inevitable. In order toprofit from the associated software developments forsimilar systems in beam transfer, the need for a commonconfiguration strategy (XPOS) was clear. The creation ofthis environment allowed the transparent migration to thenew orbit and trajectory system (MOPOS).The replacement orbit system not only has the abilityto provide multiple orbits in any point in the SPS-cyclebut also allows multiple clients to access the system inparallel. In addition, the high performance hardwareretains turn by turn beam position measurements for allpickups over the whole cycle and allows real-timecalibration during every SPS cycle.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 real-timetasks. The system allows autonomous real time control ofthe acquisition hardware, and at the same time allowsbackground data conversion to take place. Additionally,user commands (which enter via network ‘Equip’ calls)are also executed in parallel.The software consists of three sections viz. Userinterface and control modules, timing and sequencingmodules and acquisition hardware control modules.These 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 isan Unix-like RTOS, which runs on the CES RIO2PowerPC processor.The User Interface consists of three separate modules,namelyx The ‘Equip Server’ which receives commandsfrom the rest of the system via an RPC basedEquip call and passes any data back.x The command processor ‘rocsfe’ packages thecommand into an Action Structure, tagged withthe special event Now.x The Socket Server module ‘sockmod’ provides analternative, high speed TCP channel with which topass 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 by interpretingthe machine timing events (received with the TG8 timingcard) and generating a stream of logical event 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.Static versions of these tables are held on a special batterybacked, non-volatile memory board.International conference on accelerator and large experimental physics control systems (ICALEPCS)4-8 October 1999, Stazione Marittima, Trieste, Italy22.2 DMAA warning event associated with each elementary cycleinvokes a real-time task, which configures the driver ofthe MOPOS acquisition controller interface (MACI). Thisprograms the PCI bus controllers (PLX9080) to transferthe acquisition data from the FIFO memory into systemmemory. The driver interrupt service routine re-programsthe bus controller when data transfer exceeds 8 MB.Important system specifications include:x Processor PowerPC 604e/200 MHz(CES RIO2 8062)x PMC slots: 6 (CES PEB 6400)x Data Rate 8 MB/sx Acquisition Memory 224 MBx Beam data capacity 28 seconds.x 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 became evidentthat 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. An exampleof such data, is event data, which changes according tofactors 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 was chosen as a basisfor data storage, and object oriented techniques whereused in its design. Oracle 7 in particular was chosen asalready in use at CERN in the operational environment.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-layer (two-tier) development process wastherefore pursued, with Oracle Forms as the basis forrapid development for the system developers, and a Javaapplication/applet as the 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 the mainaccess to data would be through the configuration client,other operational software would also require access tothe data. If all data access mechanisms were written inJava, this would require existing operational software tobe re-written in Java. This was definitely not acceptableand so the concept of the configuration broker wasconceived.The broker provides services to clients for databasetransactions. In addition, the broker also provides actionsfor data transfer to and from the hardware. The brokermechanism 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 andDetectorDataCalibrationDataEventDataMOPOS CrateDetectorDefinitionsEventDefinitionsSupercycleDefinitionsCalibrationDefinitionsCurrent EventDefinitionsBrokerOps SoftwareJava ClientOracleInternational conference on accelerator and large experimental physics control systems (ICALEPCS)4-8 October 1999, Stazione Marittima, Trieste, Italy3broker are ready the transaction is completed. Anexample dialogue between client and broker is as follows:x Client requests service from broker.x 'Class’ and location of target system assessed.x Broker begins execution of 'class' dependant codeand returns a request ID (RID) to client.x Client free whilst request is being handled.x 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 user interfacewhich allows the user to request services and view theresults. Currently, services available from the Java clientinclude configuration of all MOPOS data, diagnostics,news, tuning, calibration and facilities to interrogate andchange the current status of hardware.The deployment of the configuration client as anapplet, offers great flexibility in terms of accessibility, butalso 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 was asubscription 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 the KLgroup.5  MULTI-TURN ANALYSISMulti turn applications require many seconds ofcalibrated turn by turn position measurements(trajectories) resulting in megabytes of data to betransferred. To obtain efficient transfer and avoid sizelimitations in buffer oriented protocols (SL-EQUIP); aTCP/IP socket was used instead. The data is transferredvia a set of pipes from the acquisition memory to anexternal process and then sent to the socket server. Manysuch external processes can be created to supply userspecific 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 and settingshandling 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 memoryhas provided an efficient means of acquiring the largeamounts of data required. As a result of using DMA theprocessor power can now be utilized to serve userrequests and provide calibrated orbits.The chosen configuration strategy achieves its goal toprovide 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 clientshas allowed home access for experts through the WWW,and the use of the applications on many platforms. Due tothe object-oriented nature of Java, sub-components of theconfiguration client can be called as stand-aloneapplications.The new plotting package supplied by the KL groupshowed that the use of Java in data analysis was feasible.REFERENCES[1] A.H.Dinius et all, “Evolution in controls methodsfor the SPS power Converters, ICALEPCS’95,Chicago, November 1995.

Real time- and control software for the new orbit measurement system for the CERN SPS

Real time- and control software for the new orbit measurement system for the CERN SPS

Abstract

Similar works

Full text

Available Versions

CERN Document Server