Laugier, I

Trofimov, N N

CERN Document Server

AbstractRecent experience when developing vacuum controlapplications at CERN made evident that a significantamount of work was induced by the variety of ApplicationProgramming Interfaces (API) in different parts of thehuge accelerator vacuum control system. A naturalsolution to the problem is to provide an isolation layer ofsoftware that will effectively decouple applications fromany dependencies on the specific interfaces by presentingits own unique API to application programmers. TheCDEV [1] package developed at TJNAF has been used asan implementation framework for this layer of software.The implementation follows a 3-tier architecture wherevacuum equipment servers, based on the CDEV "genericserver engine", act as intermediaries between applicationsand subsystem specific controls. The paper describes indetail this client-server architecture and presentsexperience with using CDEV in the CERN acceleratorcontrol environment.1 INTRODUCTIONFor the time being, all three main accelerator controlsystems at CERN (LEP, SPS and PS) use significantlydifferent protocols and interfaces for the vacuumequipment access. As a consequence, in each systemapplication programmers have to write completelydifferent code to read, for example, a pressure value from avacuum gauge.The software presented in this paper aims at hiding thesedifferences to the application programmer. The basic ideais that, despite the diversity of existing low level equipmentcontrols, at the application software level devices of thesame kind can be represented by a common control modelreflecting their prime operational purpose rather thenspecific implementations.The Common Control Model (CCM) for the vacuumequipment [2] presents a vacuum system to theapplications as a collection of logical devices. Each logicaldevice contains a number of functional componentscorresponding to physical variables in the underlyingvacuum equipment and belongs to a device class. Eachfunctional component is uniquely identified by a namewithin its device. All devices belonging to the same classhave the same nomenclature of functional components.Several classes of the functional components have beendefined in the CCM; each class provides a standardinterface to a certain type of physical device variables and,depending on the type (analog or discrete, input or output),specifies a number of attributes which applications canobserve and, in some cases, modify. For example,components of the Measurement class have value, validity,timestamp, units, minValue, maxValue, resolution andformat attributes and serve to model analog input channels.This model can be implemented on top of the existingcontrol facilities and, along with a common API, serve as abasis for portable application software.2 OVERVIEWThe prototype implementation of the model on LEP and PSaccelerators at CERN is based on the CDEV class librarydeveloped at TJNAF [1]. Basic concepts of the CDEVsoftware are very close to the control model, so themapping is rather simple and straightforward. Functionalcomponents map to CDEV device attributes, and attributesof the functional components map to CDEV properties.Figure 1:   Device server.Applications linked to the CDEV client librarycommunicate with Device Servers using the CDEVnetworking protocol (CLIP, Figure 1). The Device Serversare implemented within the CDEV Generic ServerDevice ServerSL-EQUIP PS-EQPCDEV Generic ServerLEP Vacuum Equipment PS Vacuum EquipmentApplicationCDEV ClientCLIPUSING CDEV AS MIDDLEWARE IN VACUUM EQUIPMENTCONTROLSI.Laugier, N.N.Trofimov, CERN, Geneva, SwitzerlandInternational Conference on Accelerator and Large Experimental Physics Control Systems517International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italyframework and their primary function is to map logicaldevices to the underlying physical equipment. For eachlogical device the servers provide the “stub” functionswhich link the device to physical I/O points in theequipment. The physical I/O is performed using the PS [3]and LEP [4] specific equipment access interfaces andprotocols.Since the physical I/O is relatively slow, the serversmaintain a cache for the most recent data read from theequipment. Applications read device attribute values fromthe cache; the cache data is periodically updated so that italways reflects with a required precision current state of thephysical equipment attached to the server. Upon each cacheupdate, the applications that subscribed to (monitorOn)values of device attributes can be notified on changes if thedata received from equipment is different from the cacheddata.3 CONFIGURATION DATAOne of the main goals in the Device Server design was tomake the server software, as much as possible, data driven.In particular, it shall be possible to introduce a new deviceclass in the control model or a new device in the systemwithout recompilation, just by entering the device or theclass descriptor into a configuration database. In theprototype implementation, the general accelerator (Oracle)database was used to store the configuration data.Figure 2:   Data Server.Since access to the accelerator database is relatively slowand not always guaranteed, the two level data extractionscheme is used (Figure 2). Information from Oracle datatables is dumped into files that are read at startup by theData Server which then acts as an actual data source for theDevice Servers and applications.The Data Server is also implemented using the CDEVGeneric Server framework and is seen by its clients as aspecial "well known" database device that responds to theselect, query and get messages. The first two messagesclients can use to locate a required descriptor in thedatabase. When the descriptor is found, its contents can beobtained from the database using the get message.With this approach, we practically do not use thecdevDirectory device and DDL files. The DDL file in useonly describes interfaces to the CDEV name server and theData Server. All directory services are provided by thedatabase device.4 DEVICE SERVER SOFTWAREThe Device Server software is written in C++. Classesshown in Figure 3 constitute the server framework;altogether, they allow to create, according to the databasedescription, the software objects which represent logicaldevices and “export” them over the network to clientapplications..Figure 3:   Object model for the Device Server.Data ServerCDEV Generic Serverin-memorydata tablesApplicationCDEV ClientDevice ServerCDEV ClientCLIPAccelerator DatabaseOracle data tablesData FilescdevServerrunServerDeviceServerprocessMessagesDevicecreateComponentgetsetinstallMonitorremoveMonitorupdatefireMonitorTimerintervalinitializereadwriteIOHandlerIOHandleattachHandle0..1namename1*monitors1cdevMonitorNodeupdateTimer componentcomponentIOhandle0..1handler 11device 1handler 11111CDEV Library ClassescdevMonitorTableremoveMonitorinsertMonitor*518The server main function simply creates a DeviceServerobject giving the server name as an argument to theconstructor.The constructor locates the server description in thedatabase using the name as a key and extracts from thedatabase a list of all devices attached to the server. It theniterates through the list calling for each device the staticcreate method of the Device class.The create method in turn extracts from the database aclass description for the specified device and for eachfunctional component defined in this device class creates acorresponding Component object. At this point, it alsocreates a Timer and an IOHandle for the Component.The Timer will periodically activate the Component updatemethod which refreshes the Component attribute valueswith new data obtained from the equipment. If the valueschange during the update, the method can fire monitorsinstalled on the Component and hence report the changesto all interested clients. The Timer interval value is set fromthe database according to the sampling rate required tofollow changes of the corresponding physical variable.The physical I/O during the Component update procedureis performed using the read method of the associatedIOHandle object. The IOHandle is an abstract class whichjust defines a common interface to the I/O operations. Aconcrete implementation must be provided for eachspecific I/O connection.Logical devices, even of the same class, can map to manydifferent hardware “boxes” connected to the controlsystem in different ways. The IOHandler is a collection ofthe IOHandles required to connect a logical device to sometype of the physical equipment via certain I/O interface.For each logical device, the configuration databasespecifies the name of its IOHandler. The create method ofthe Device class extracts this information from thedatabase and dynamically attaches appropriate IOHandlesto the device Components.Component attributes can be dynamic if their valueschange during the operation of the vacuum device (thepressure value, for example) or static otherwise. The staticattributes, such as units of measurement, typically get theirvalues from the configuration database during theComponent creation. In some cases, they can be initializedfrom the device hardware using the init method of theIOHandle class.When the server is populated with Device objects, the mainfunction invokes the runServer method of the cdevServerclass and the server starts to accept client connections andprocess incoming messages. The communications arehandled by the CDEV library classes; incoming messagesfrom connected clients are buffered in the input queue andthen dispatched to the processMessages method of theDeviceServer class.The method first locates the Device and the Component towhich a message is targeted and then, depending on themessage type (get, set, monitorOn, monitorOff), invokesone of the Component accessor functions (get, set,installMonitor, removeMonitor).The get function packs values of the Component attributesspecified in the message context into a cdevData object andsend this object back to the client in the response message.The set function assigns new values to the Componentattributes specified in the inbound cdevData object andthen downloads the values to the equipment using the writemethod of the IOHandle class. The install/removeMonitorfunctions call corresponding methods of thecdevMonitorTable class to register/unregister a monitor onthe Component attributes specified in the message context.The message processing and the regular update ofComponent attribute values are performed in different(POSIX) threads to allow the server to handle clientrequests during relatively long I/O operations. In eachComponent, a mutex prevents simultaneous access to theComponent data from the message handling and updatethreads.5 RESULTSSeveral device servers providing access to more then athousand vacuum devices of the PS complex are inoperation for over a year now. The device server for thevacuum equipment of the new Antiproton Decelerator hasbeen successfully used in the commissioning of themachine [5]. The server software has proved to be reliableand showed performance adequate for vacuum controlapplications.6 REFERENCES[1] Jie Chen et al., ‘CDEV: An Object-Oriented ClassLibrary for Developing Device Control Applications’,ICALEPCS’95, Chicago, 1996.[2] I.Laugier, P.M.Strubin, N.N.Trofimov, ‘A CommonControl Model for Vacuum Equipment at CERN’,ICALEPCS’99, Trieste, 1999.[3] F. Di Maio, A.Risso, ‘The CERN-PS EquipmentAccess Library’, CERN PS/CO Note 93-87, 1994.[4] P.Charrue et al., ‘The Equipment Access Software for aDistributed UNIX-Based Accelerator Control System’,ICALEPCS’93, Berlin, 1993.[5] P.M.Strubin et al., ‘First Experience with Control andOperational Models for Vacuum Equipment in the ADDecelerator’, PAC’99, New York City, 1999.519

Using CDEV as Middleware in Vacuum Equipment Controls

Abstract

Similar works

Full text

Available Versions

CERN Document Server