Casella, R

Gurd, D P

Lally, K

Malitsky, N

Peng, S

Smith, J

CERN Document Server

DESIGN OF A UNIFIED CONTROL SYSTEM APIN.Malitsky, R.Casella, K.Lally, S.Peng, J.Smith, BNL, Upton, USAD.Gurd, LANL, Los Alamos, USAAbstract This paper presents the design of a unified controlsystem API.1  MOTIVATION     The accelerator control client-server environment isbuilt after the ISO reference multi-layer model whereeach layer provides a service interface to the layer aboveand protocols for communicating with the correspondinglayers in other systems. There is a mismatch betweenobject-oriented application semantics and a low-levelcontrol interface. Several accelerator tools address thistask by providing uniform generic ApplicationProgramming Interfaces (API) to heterogeneousaccelerator devices. A generic interface is a veryeffective approach for integrating open mutable diverseunderlying systems. However, its highly adaptivearchitecture introduces significant overhead forapplication and system developers requiring them toexplicitly support and employ proprietary API-specificmeta-facilities and communication requests. Also, ageneric service does not specify application domain datatypes and can not act as an object-oriented frameworkfor high-level accelerator applications. The modernindustrial technologies address this task by providing theobject-oriented approach in developing distributedsystems. They not only automate many routineprocedures, but also create a basis for integratingaccelerator application design patterns and frameworksinto the control system environment. The next sectionsdescribe how to apply these technologies for developinga unified control system API.2  SELECTION OF SOFTWARETECHNOLOGIES2.1  Programming LanguageThe choice of programming language is determinedby several criteria: (1) support of the modernmethodology; (2) the quality and quantity of associatedlibraries, extensions, and products; and (3) its popularity.At this time, most object-oriented applications arewritten in C++ or Java. The recent release of the secondversion of the Java Development Kit (JDK 2) and thespecification of the Java 2 Enterprise Edition Platform(J2EE) has shifted the balance between two competitivelanguages. The Java 2 not only solves the C++portability problem and implements the latest ANSI/ISOC++ Standard features, but also offers a rich set ofintegrated technologies and tools that significantlyfacilitate developing distributed scientific and controlapplications. For example, a meta-facility takes anessential part of the modern C++ accelerator controlsystem frameworks and the Java reflection mechanismallows software developers to avoid the maintenance ofproprietary accelerator-specific meta-languages (such asADO .rad files or the CDEV Device DefinitionLanguage). Also, the previous Java version, JDK 1.1,limited Java developers to the client part of the multi-tierdistributed systems. The Enterprise JavaBeans (EJB)specification and Java 2 performance enhancements (e.g.JIT compilers) have opened new possibilities fordeveloping Java-based client-server systems. Tocompare C++ and Java compilers we run on the SunUltra (Solaris 2.7) computer a simple test performingmultiplication on the elements of a large array ofdoubles (see Table 1).Table 1: Average time of multiplication and copy on the1000000 elements of an array of doubles.Language Optimization Avg. Time (ms)Sun CC 4.2 -fast 51egcs-2.91.66 -O3 75Java 85    The next generation of Java compilers, the HotSpotPerformance Engine, aims to provide additionalperformance enhancements to the Java platform. TheHotSpot compiler is based on the adaptive optimizationtechnology that identifies and precompiles the mostfrequently used methods and statements of long runningsystems. We plan to benchmark its power on real-sizeprototypes of  accelerator applications.2.2  Middleware    The accelerator control systems have to rely on therobust and high-performance infrastructure. The efficientcommunication between distributed components can beachieved with the low level transport mechanisms, suchas BSD sockets, Windows NT named pipes, or Sunremote-procedure call (RPC) libraries. However, thesemechanisms lack type-safe, portable, reentrant, andextensible interfaces, and require the additional adaptersfor being embedded into object-oriented applications. Tosolve these and other problems, the Object ManagementGroup consortium has introduced the Common ObjectRequest Broker Architecture (CORBA), an industrialInternational Conference on Accelerator and Large Experimental Physics Control Systems505International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italystandard for developing scalable interoperable object-oriented distributed systems. CORBA not onlyautomates the process of marshaling domain objects intotransport layer, but also offers a rich set of supportingservices, such as Naming, Event, Transaction, and manyothers. The recent implementation of the CORBAInternet Inter-ORB Protocol (IIOP) in the Java RemoteMethod Interface (RMI) brings CORBA technologies tothe Java conventional environment. Figure 1 shows theperformance comparison of the Sun RMI-IIOPmiddleware with BSD sockets, Sun RPC, and TAO(C++ high-performance real-time ORB). The remoteroundtrip times were measured between Ultra-Enterprise400 MHz machines running Solaris 2.7 and located ondifferent subnets.2.3  Component-Oriented Framework    The design and implementation of the applicationdomain frameworks involve significant efforts inevaluating, developing, and integrating reusablecollaborative components. The modern component-oriented frameworks, such as Sun Enterprise Java Beans(EJB), CORBA Component Model (CCM), andMicrosoft COM, facilitate and direct the softwaredevelopment process by providing a standard-basedhorizontal platform, a factory of specialized verticaldomain environments. At this time the EJB architectureis the most advanced, mature, and promising technology.It takes a central part of the Java 2 Platform, EnterpriseEdition (J2EE), and the CORBA CCM specificationdefines the consistent interoperable mechanism fordeploying EJB objects in the future CCM environment.    EJB architecture divides all domain objects into twocategories: Entity Beans and Session Beans. Entity Beanrepresents a persistent coarse-grained identified domainobject that can be shared among multiple clients. SessionBean can be a service or a conversational session with aparticular client. All EJB objects are executed in the EJBcontainer’s run-time environment that provides a unifiedstandard interface to the common industrial services,such as lifecycle management, persistence, transactions,and many others.  In the next section, we show therelationship between the EJB architecture andaccelerator framework patterns.3 CONTROL SYSTEM API   A control system API unifies the three components:Accelerator Model, Device API, and AcceleratorIntegrator (see Fig. 2).Mapper Element DevicePersistent data Run-time dataDistributed ResourcesAccelerator Integrator Accelerator Model Device APIUnified Control System APIApplication Software3.1  Accelerator ModelThe description of accelerator structures is a key partof accelerator programs. Accelerator combines manyelements of different physical types with heterogeneousattributes, all organized in a nested hierarchicalstructure. The complexity of this organization prompts avariety of project-specific views and implementations ofaccelerator models. The diversity of different modelsprevents the comparison, selection, and integration ofreusable algorithms and applications. The recentAccelerator Description eXchange Format (ADXF)proposal aimed to provide a uniform, complete, andextensible approach in the definition of the acceleratorstate. The concepts described in this proposal are basedon the Standard Input Format (SIF), Standard MachineFormat (SMF), Standard eXchange Format (SXF) andexperience with actual accelerator applications, such asRHIC, SNS, LHC, CESR, FNAL Main Injector, andothers.The original version of the ADXF proposal has beenmapped into the Extensible Markup Language (XML),an industrial standard for processing Web documentsand application-neutral data. In this paper, we haveimplemented its object model into two otherrepresentations: relational database tables and Javainterfaces.The ADXF database schema is described in Table 2.The Accelerator Node table keeps references to allaccelerator nodes. Beamline is an intermediary linkingtable that represents the many-to-many relationshipsbetween elements and sequences of elements. Nodeattributes are distributed in the different elementbuckets. Each bucket has its own table to accommodatea fixed set of element attributes. The Multipole Buckettable illustrates the use of embedded virtual arrays in anOracle table with knl and ktl fields. It is a new feature ofOracle 8i and is supported in SQL 3 and JDBC 2.0specifications. Each accelerator element may alsoinclude insertions, other accelerator nodes (e.g. detectorAverage Time per Call050010001500200025003000350040004500void/long[256] long[256]/long[256]Time (usec)Local RPC Local TAO Local RMI-IOPBSD Sockets Remote RPC Remote TAORemote RMI-IOP506solenoid). This many-to-many relationship is representedby the Element Insertions table.Table 2: ADXF schemaTable ColumnsAccelerator Node ID, NODE_TYPE, DESIGN_IDBeamline ID, POSITION, NODE_IDElement Buckets ID, BUCKET_INDEX,BUCKET_TYPEElement Insertions ID, POSITION, NODE_IDBasic Bucket BUCKET_INDEX,BUCKET_TYPEMultipole Bucket BUCKET_INDEX, KNL, KTLOther Element Buckets. . .   The ADXF  model has been evaluated also in the JavaRMI-IIOP-based distributed environment. Client andserver communication stubs for accelerator nodes havebeen generated by the Sun rmic compiler from theAcceleratorNode remote interface. The interfacebetween application server objects and Oracle is basedon the standard Java JDBC technology.3.2  Accelerator Device APIAccelerator Device represents an identifiedaccelerator physical entity which actual run-timeparameters can be accessed, controlled, and monitoredby accelerator applications. In most control softwarepackages, the structure of the Accelerator Device isdescribed by the following model:• Accelerator Device contains a collection ofParameters.• Parameter has a value and Properties. There areseveral types of Parameters that are characterizedby fixed sets of associated Properties.This Accelerator Device and the ADXF Element havethe same two-level structure: a dynamic collection ofstatically defined data sets.  This structure facilitatesselection and classification of well-defined concrete datatypes. On the other hand, it provides a consistentextensible mechanism for describing and integrating newelement parameters. Also, Accelerator Device andADXF Element models complement each other and canbe connected according to the following formula: avalue of Accelerator Device parameter is an attribute ofthe corresponding Element. It means that AcceleratorDevice may act as a service for comparing orsynchronizing the Accelerator Model attributes withactual run-time data.    Employing the CORBA technology significantlyfacilitates the implementation of the Accelerator Devicemodel in the distributed control environment andprovides the following benefits: simultaneous support ofgeneric and object-oriented interfaces to remoteaccelerator devices and extension of communicationdata types by objects. On the other hand, the CORBA isa highly adaptable technology and permits theincremental integration of its components with existinglow–level control system interfaces, such as EPICSChannel Access and ADO classes.3.3  Accelerator Integrator   The Accelerator Integrator is a computational enginethat simulates diverse beam dynamic processes andtransforms accelerator data into accelerator physicsmodeling abstractions (such as Twiss parameters, Taylormaps, etc.) for high-level applications. Acceleratorphysics (as any other scientific domain) is characterizedby a variety of different algorithms and approaches.Usually, a choice of the optimal solution is a difficulttradeoff among many project-specific factors. The UALframework infrastructure addresses this task by defininga universal mechanism for assembly and reuse ofindependently developed accelerator algorithms.    The mechanism is based on the Element-AlgorithmProbe analysis pattern that introduces three collaborativeclasses: Element (e.g. Quadrupole), Algorithm (e.g.QuadrupoleTracker), and Probe (e.g. Bunch). Thisstructure is very similar to the  EJB architecture andmakes straightforward its implementation in the EJBenvironment. The Accelerator element is an identifiedpersistent object that corresponds to the EJB Entity Beansemantics. The Algorithm does not have a persistentstate and can be implemented as a stateless or statefulEJB Session Bean. The Probe is used for data exchangebetween different Algorithms and fits to a Java serializedobject.   The implementation of the Element-Algorithm-Probeanalysis pattern is based on the Mutable Class designpattern. A Mutable Class divides a class into two parts, aType class and Instance class, and delegates anInstance’s behavior to Type. The Type object isimplemented as a singleton, that serves as a Manager(factory and finder) of Instance objects.  For acceleratorelements of the same type (e.g. sector magnet) there is aseparate manager (e.g. SBendManager) and associatedalgorithm managers (e.g. SBendTrackerManager) TheType-Manager singletons can be grouped together in theuniform collection and be controlled by the separateobject, a Type Registry (finder). One can consider anAlgorithm Registry as an alternative approach to aVisitor for open configurable systems.  In the EJBenvironment, Element and Algorithm Managerscorrespond to EJB Homes that are automaticallygenerated for each element types.    Architectural principles of the Element-Algorithm-Probe framework have been tested with the BullSoftfreely available open source implementation of the EJBspecifications.   We thank S.Sathe, J.Song, and J.Wei for many usefuldiscussions.507

Design of a Unified Control System API

Abstract

Similar works

Full text

Available Versions

CERN Document Server