Jeram, B

Kriznar, I

Lesjak, B

Milharcic, T

Plesko, M

Sabjan, R

Tkacik, G

Verstovsek, I

Zagar, K

CERN Document Server

DISTRIBUTED COMPONENTS IN CONTROLSM. Plesko, B. Jeram, I. Kriznar, B. Lesjak, T. Milharcic, R. Sabjan, G. Tkacik,I. Verstovsek, K. Zagar; J. Stefan Institute, Ljubljana, Slovenia, http://kgb.ijs.siAbstractWe have built a control system framework that usesand extends modern component-based, distributedcomputing and object-oriented concepts. The basicentities of the system are accelerator devices that arerepresented as CORBA objects. Each device is furthercomposed of property objects that correspond to what iscalled channels in EPICS. Properties support get/setcommands, event-driven monitors and alarms,asynchronous and synchronous communication, logging,access to the database, etc. As all devices and theirproperties have common functionality, the servers forthose CORBA objects are generated with a wizard-likeprogram generator. Another generator creates one JavaBean component for each CORBA object. The clientapplications, written in Java, are then composed of those"accelerator components" in any commercialdevelopment tool, often using visual and graphicalprogramming. The Beans are essentially componentswrapped around CORBA, because standard CORBAcomponents do not exist as yet. However, they are morepowerful as they contain a pluggable interface thatconnects to any communication framework apart fromCORBA, such as CDEV or even a generic simulation ofdevices and properties. The plugs are determined andswitched at run-time. Generic applications that cover allbasic needs including machine physics applications havebeen made using CORBA dynamic invocation and Javareflection. The functionality of the system is rounded upby a series of tools based on a remote managementframework, which is composed of security/authorizationmechanisms, object and process management,configuration database versioning and rollback, controlevent logging, and similar.1 INTRODUCTIONThe presented distributed component framework formsthe core of the control system for the light source ANKAat the Forschungszentrum Karlsruhe in Germany. The2.5 GeV storage ring of ANKA is just beingcommissioned and should be operational by spring 2000.The ANKA control system[1], which is completelyoutsourced to the J. Stefan Institute, builds on the three-tier standard model architecture. Modern products basedon standards in distributed objects and networking areapplied in addition to low-cost hardware including PCs.The LonWorks field bus network with intelligent nodesand standard I/O modules connect the individual devicesdirectly to PCs. The communication to these “deviceserver” PCs is done through CORBA[2]. Other PCs onthe net run Java clients that wrap CORBA objects intoJava Beans[3], which are then connected withcommercial data-manipulation and visualisation Beansusing visual tools or programmatically. The CORBAobjects and Java Beans are generic models of controlleddata that can be used at any other control system.2 OBJECT ORIENTED COMPONENTS2.1 ConceptsA crude definition of software component is “areusable piece of code”. However, such a productdeveloped for the in-house use has little chance of beingadapted for general use and re-use even if it is free andefficient, unless it fulfils the following conditions:• it is easy to use, which includes being easy to learn• it employs standard programming practices andadheres to well-defined and established frameworks• it is flexible in the sense of being easily ported,adapted or extendedSome of these requirements are satisfied automaticallyby the object-oriented programming (OOP) practice.Ease of use, however, necessitates another step, that isthe use of component technology (OOP that uses existingcomponent frameworks and sticks to certain designguidelines / patterns).Our components - Accelerator Beans or Abeans[3] forshort - for rapid application development of acceleratorcontrol client software meet these requirements by:• using Java Beans technology, thus enabling the userto build the panels visually, while the developmentenvironment generates the code• enforcing strict separation between components thathave no visual representation but represent thecommunication, error handling, synchronisation andsimilar frameworks; and components that offerstrictly visual capabilities but are not aware of thefact that remote objects are being controlled throughthem• separating the communication system dependentfunctionality into separate modules, called plugs,which can be dynamically loaded: porting Abeansconsequently requires only the plug (interface to theunderlying control system) to be written, while allInternational Conference on Accelerator and Large Experimental Physics Control Systems541International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italyupper layers (frameworks, visual components andapplications) remain totally unaffected.2.2 Component HierarchyWhen writing a client application the programmer ismost often confronted with numerous problems from theareas of error handling, timeout handling, logging,communication system details, resource initialisation anddestruction and the like. In terms of lines of code it caneasily happen that such functionality easily compareswith the core application functionality. The samereasoning applies to GUI programming. A divide-and-conquer solution that ANKA client software embraces isthe use of the following approaches:• Control system is comprised of server layers andclient layers; the latter consist of framework(invisible) Abeans layer (which in turn consists ofserver-dependent or pluggable layer and independentlayer), and application (visible) layer• There can be many types of controlled devices andtherefore many different interfaces (one device - oneclass approach), however, each device is constructedof fundamental building blocks - Properties, andthere is only a small number of these(RWDoubleProperty represents a physical quantityof double type that can be either changed orretrieved, for instance a current in a power supply;there are currently 3 such types in ANKA CS:RWDoubleProperty, RODoubleProperty,ROPatternProperty, representing a retrievable bit-pattern)• The core visual components (such as gauges, statusdisplays, trend charts) should be completelyindependent of the actual control system, so that theycan be used by others• Special adapters have intimate knowledge about theProperty and about the visual component, allowing ageneric visual component to be "adapted" to theProperty. This means that the Property will be aninvisible framework class and the generic visualcomponent will, with the help of an adapter, becomeits view (to use the Model-Controller-Viewterminology).In this way, the learning curve for a new programmeris not very steep and demanding. For instance, ANKAcontrol system uses CORBA for communication, butprogrammers writing the visual components or "views"are completely unaware of CORBA, since the invisibleAbeans layer hides it. All interactions with the datasources that the view needs to display its data isperformed through simple and well-defined Java Beansinterfaces.The pluggable layer offers the possibility of accessingdifferent remote systems and by its nature of adapting thelower-level remote system interface to the Abeaninterface enforces uniform and consistent behaviouracross a range of possible remote systems.3 CORBA OBJECTSWe believe that the most human-oriented way is torepresent each accelerator device with a respective object.CORBA allows very fine-grained definition of objectsand their properties. With a control system we controlaccelerator devices, such as power supplies, beamposition monitors, etc. So it is natural that we representthose devices in the computer with objects. In thenetwork, they become CORBA objects.The example analysis of a power supply in Table 1shows how a device object looks and what kind ofproperties it has.Table 1: properties and commands of a power supply:Property Type AccessADC: double Read onlyDAC: double Read/writeStatus bits Read onlyCommand Input type Return valueon(): none voidoff(): none voidWe see that properties have different types and alsodiffer in whether they are read-only or also can bewritten to. But there is more to properties. A property,such as power supply current, has properties of its own: aminimum, a maximum, a description, units, etc. Toavoid confusion, the properties of properties are calledcharacteristics.In most cases, all properties have the same type ofcharacteristics. There is a difference between read-onlyand read-write properties, as the former have nocommand to write. Another difference is betweenproperties of type double and type bits (actually anunsigned integer containing a bit pattern), as the latterhave no minimum or maximum. But all these differencescan be systematized into a matrix of few classes[2].4 THE IMPLEMENTATIONAlthough the control system is designed to support allprimitive data types for controlled values, only doubleand unsigned integer did suffice. In turn, the number ofnecessary GUI components is small. Not only were thetypes of values limited, also their properties were definedand fixed in advance. This means that a controlled valueis either read-write or read-only and that it has a name, aminimum, a maximum, etc.4.1 GeneratorsThe list of properties was made large and configurableenough to cover .all cases, yet the sole fact that it is fixed542in advanced simplified the design of clients and serversand databases.Also the device servers and the API are then devicespecific, however due to the pre-defined value types andstructures, all those components can be built easily andfast. In fact, a wizard has been written which generateddevice servers based on device interface definitions. TheJava API libraries, JavaBeans, need less than one page ofextra code per device. So in total, the concept proved tobe advantageous.4.2 System ManagementThe functionality of the implemented objectmanagement would shortly be described as:A: view current state of control system• state of Device Servers• name of computer, where Device Server is running• shows exported and exportable Devices of eachDevice Server• state of DevicesB: management of Device Servers• download component database to local disc whereDevice Server is located• change of component database location• shutdown, restartC: management of individual Devices• destroy, export of Device with DeviceServer• activate, deactivate• show and manage all clients connected to Device4.3 The Component DatabaseThe component database stores hierarchicallyorganized data. Data may be in form of simple type, suchas String, Double, Integer, or organized in arrays orobjects. Data are stored in text files (*.txt) that are placedin structure of folders. The path to each piece of dataconsists of directory path, name of file and it'sdeclaration in file. The files may be edited manually withtext editor, such as Notepad. The data stored are physicalcharacteristics of accelerator devices and propertiesneeded to communicate with devices. This data is static,it doesn't change much, except when new devices areadded or old removed. Therefore the component databaseis also called staticDB. The database is located on localcomputer, where device servers are running.A device server reads data from StaticDB in form ofattributes. An attribute consists of path name and value.The value of an attribute can have data type, simple orcomplex as Array or Object. The path name isdescription of location in StaticDB architecture wherevalue is stored.Expressions and variables can be used for Integer andDouble type. Supported operations are: +, -, *, /, ^, sin(),cos(), sqrt() and exp(). Variables are all names of valuesdefined in the same file. In language of paths this meansthat as a variable in an expression any node name can beused that has the same parent node as the evaluated node.Templates are used when a group of attributes hassame data value or to provide them a default value. Insuch case is wise to store this value in one place, so onlyone rending is necessary when value should be changed.Templates also ease StaticDB managing and building.When StaticDB can't find an attribute value in the givenpath, it will look into template locations that are definedinside the attribute paths. There can be more then onetemplate location.For version control of the database Microsoft VisualSourceSafe is used. The central version of StaticDB isstored as a SourceSafe database on one computer in thelocal Microsoft network. The recommended tool forediting files is TextViewer (Textview.exe) which isincluded in NT Resource Kit. On the left side of theprogram window is a visible structure of folders and filesin StaticDB, on the right is the visible contents ofselected file. For Reading and comparing StaticDB twotools are provided: DBReader reads single attributesfrom StaticDB; DBCompare analyzes the wholeStaticDB and prints out selected attributes, all attributesor all unreadable attributes. DBCompare also comparesone StaticDB to another.CONCLUSIONSExperiences with the running system for the ANKAlight source show that the concept lives to its promises. Asuccessful port of the Java Beans to a test case at theSwiss Light Source, where the calls to CORBA werereplaced with calls to CDEV, is a proof that the strictobject oriented model of devices can be used toeffectively hide other types of communication channels.The Abeans present the final user with a view of theaccelerator as a collection of accelerator beans, therebyreducing the problem of writing applications for thecontrol system to the problem of familiarizing oneselfwith the ways to use java beans and development tools.All interfaces that Abeans expose are type-safe (withno 'single function taking control string' methods) andenable one to construct a simple yet powerful graphicapplication within minutes.REFERENCES[1] M. Plesko et al, A Control System Based on Web,Java, CORBA and Fieldbus Technologies,PCaPAC99 workshop, Tsukuba, January 1999.[2] M. Plesko, Implementing Distributed ControlledObjects with CORBA, PCaPAC99 workshop,Tsukuba, January 1999.[3] G. Tkacik, Java Beans of Accelerator Devices forRapid Application Development, PCaPAC99workshop, Tsukuba, January 1999.543

Distributed Components in Controls

Distributed Components in Controls

Abstract

Similar works

Full text

Available Versions

CERN Document Server