Clausen, M

Gerke, C

Khvorostyanov, A G

Klinger, V

Loukyantsev, A

CERN Document Server

THE USE OF ORACLE FOR DEVELOPMENT AND MAINTENANCE OFEPICS DATABASESA.. Lukyantsev, A. Khvorostianov, IHEP, Protvino, RussiaM. Clausen, Chr. Gerke, V. Klinger, DESY, Hamburg, GermanyAbstractThe use of EPICS [1] in a part of the DESYaccelerator controls has initialized the development ofspecial tools to create and maintain IOC (Input OutputController) databases containing tens of thousands ofEPICS records. This paper presents the process ofdesigning IOC db`s and the relevant tools for supportingIOC db`s by ORACLE[2] facilities developed usingORACLE FORMS[3]. The process of designing aconcrete IOC database includes the definition of a set ofEPICS records, the assignment of names to recordsaccording to the certain rules and the setting of values tofields of records distinct from initial values determinedby types of EPICS records. As a number of IOC db`s canhave groups of records, which differ only by their namesand by the values of individual fields of records,individual prototypes for such groups are defined. Therequirements on the tools to create and maintain IOCdb’s are:• The satisfaction of the various users of acceleratorcontrols;• The storage all IOC db in a unified base, whichallows to coordinate the information in thedeveloped IOC db (for example, guarantee ofuniqueness of record names in all IOC db);• The formalization of several procedures in orderto simplify the process of designing IOC db`s,large amounts of information brought into IOCdb`s;• The parallel maintenance of IOC db for differentEPICS releases (i.e. translation of IOC db fromone EPICS release to another);• The development of data structures which wouldsupport both old and new definitions of EPICSdatabases.We created a new form in ORACLE called EpicsOrain which the basic principles of how we design an IOCdb are realized.1 STAGES THE DESIGNING PROCESSIn the offered process of designing IOC db`s it ispossible to run through three basic stages. Each stagecorresponds to a tool in the program module and a datastructure:• EPICS dbd (database definition): Stage ofdatabase definitions for EPICS releases inORACLE. The appropriate section of the datastructure includes the descriptions of EPICSrecord types, menus etc. At this stage the textualfiles (*.dbd files) contain the database definitionsfor the concrete EPICS release, the descriptionsfor each record type, menus, table of breakpointsetc. are imported into ORACLE. The data inputprocedures support the database definition filesand the ASCII files for the Epics R3.12XXXreleases, and the “dbd” and database (“db”) files -for the Epics R3.13XXX release.• PROTOTYPES: Design stage of the groups andrecords prototypes. The appropriate section of thedata structure includes the descriptions of thegroups prototypes and of EPICS recordsprototypes which are under construction on thebasis of EPICS dbd objects. Hereinafter objects weshall understand types of records, prototypes ofgroups, projects, group, IOC databases and otherelements of the data structure.• PROJECTS: Design stage of IOC db`s of theprojects. The appropriate section of the datastructure includes a set of the projects, each ofwhich contains a number of IOC db, consisting ofconcrete EPICS records. The descriptions of theobjects at this level are formed on the basis of theobject descriptions of the previous levels.The levels of object’s designing and their priorities areillustrated in Fig. 1.1.1 Creation of Groups and Records PrototypesAt the stage PROTOTYPES the prototypes for anumber of objects are created. Groups of EPICS recordswith identical record types and the same values for theproperties can be shared between several IOC databasesif they are collected in prototypes. They must be createdbeforehand in order to use these prototypes for new IOCdatabases. On the basis of these concrete groups IOC dbcan be projected.International Conference on Accelerator and Large Experimental Physics Control Systems460International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, ItalySome of the fields of EPICS records have initial valueswhich are defined in the description of the given recordtype. These initial values are simply inherited. Otherfields of the records in a group have values which aredistinct from the initial values, but identical to all IOCdb’s, in which the given group is used. The values ofsuch fields are set at creation time of the prototype ofsuch a group and then are inherited at the design time ofthe concrete group of EPICS records for an IOC db.Other fields of records have values that depend onvarious conditions or on the relations between projectedobjects. For example, whether the record belongs to theproject, the IOC db or to the group. In this case thedefinition of values of such fields is formalized by meansof the use of variables. When instantiating a concreteobject (project, IOC db, group etc.) the values ofrequired variables are determined and assigned to theobject. These values of variables are further substituted infields of records containing these variables and havingrelations to this object. The values of variables inconcrete records are inherited on a priority and aresubstituted in fields of this record. For example, let’screate a project containing some IOC db’s each of whichincludes its own set of groups and records. The value of afield in a record contains a variable, it is defined at firstas the value of the variable which is an attribute of thegroup. If the variable is not determined on group level,the IOC db is searched, and then the project. If the valueof a variable which itself is an attribute of an objectchanges, it will result in a change of the values of allfields of concrete records, into which the given variableenters, and to which (EPICS records) relate for the givenobject.Those fields of records in a group which shall havedifferent values for different IOC db are marked at thedesign time of the group prototype as fields whichrequire obligatory setting of individual values. Duringthe design of the concrete group of IOC db records theyare viewed as a list for all group record/fields. This is auser-friendly interface where only those record/fieldentries that need individual data entries are shown.Let's say some words about how we form uniquenames for records and the fields of the recordsprototypes. The mnemonics of a record name containsthe information about I/O controllers, about a subsystem,which it serves, about a record type and functionality,about the location of the device to which the recordcorresponds etc. Uniqueness of records prototypes namesis guaranteed within the framework of the groupprototype. For the names of the record prototypes maskshave been implemented that include variables. Thenames of the variables consist of two symbols: % and aletter or figure. Two masks are now determined:%F%D%L _ of %T - for records such as “device” and%I%G%P _ %T - for records of all other types. Thesemantics of variable is, that it bears the information onany object, to which the given record relates. So in abovementioned masks variables concern accordingly: %I -IOC, %G - group, %P - group prototype, %T - recordtype, %F - facility, %D - device, %L -location. Atcreation of the record prototype the appropriate mask istaken, the value of variable %T is substituted only andthus the name of the record prototype is formed which inturn is a mask for the formation of a name of a concreterecord constructed on the given prototype. So, at creationof the group prototype the following operations arecarried out:• the set of the records prototypes which areincluded in the group prototype, is specified;EPICSreleaseRecordTypePrototype levelGroupPrototypeRecordPrototypeProject IOC db Group RecordProject levelEPICS dbd levelLevelpriorityInheritance ofinformationFigure 1: The scheme of object’s design levels and priorities.461• the names of the records prototypes are specifiedwhich are masks for names of concrete records;• the values of record fields are set which areinherited in fields of concrete EPICS records;• those fields of records are marked, whose valuesmust be defined at creation of the concrete EPICSrecord.The realization of the two-level structure for thegroups prototypes allows the group prototype to be builton the base of already created ones. This is useful whenthe prototype created for one project becomes a GeneralPrototype. This way it is possible to reuse the GeneralPrototype with small changes for another ProjectPrototype. In this Project Prototype the informationconcerning the concrete project is already set.1.2 Creation of the IOC db projectsAt the PROJECTS stage, the concrete projects are builtbased on objects defined in the previous stages. First, theproject is created, then within the framework of theproject, the IOC db’s are created, and further in theframework of IOC db`s, the groups of records (or simplysingle records, not concerning to groups) are created.Variables are introduced in the IOC db in order tostructure and formalize the design. The variables areused in the names of the EPICS prototype records and inthe fields of the records. The semantics of the variable isrelated, as a rule, to the created object. To define a newvariable it is necessary to assign a variable name, tochoose the object it will be related to and to describe thesemantics of the variable. The following objects now aredetermined which the user can choose from: a record (1),a prototype of groups (2), a prototype of a record (3), aproject (4), an IOC db (5), groups (6) or records (7). Thepriority of inheritance in ascending order is specified inbrackets. For example, let variable %X is determined andthe objects 4,5,6 are chosen. Let's design the groupprototype P1, in which the value of one of the fields of arecord will be defined by means of the variable %X. Let'screate the project A, consisting from several IOC db - I1,I2, I3, each of which contains groups G1, G2, G3, builtup on the basis of the group prototype, P1. While thevariable is not assigned in one of the objects A, I1, I2,I3, G1, G2, G3, the value of the fields determined bythe variable %X in records of the project A will not begiven and will be empty. If %X=value1 for the project A,then for all records of the project A the value of thefields determined by variable %X, becomes equal value1.If %X=value2 for I1, only for the records in IOC db I1the value of the appropriate fields becomes equal value2.If %X=value3 for G1 from I1, only for the records ofgroup G1 in IOC I1 the value of the appropriate fieldswill change to value3.2 EPICSORA FORMAccording to the IOC db design process a specificOracle Form has been developed which corresponds tothe design stage: EPICS dbd – maintenance of the Epicsreleases, PROTOTYPES - designing of the groupsprototypes, PROJECTS - designing IOC db of theprojects. At the startup of the form the user has to choosethe EPICS release, which he will work with, then themain window of the form is displayed from which it ispossible to start one of the above listed design stages.In the functional menu of the form the calls ofcommon procedures are assembled which can be called atthe various moments of work with the form. Amongthem are the export and import procedures from/to theORACLE database in ASCII files.Each section of the form starts with the catalogue ofobjects which can be choosen from. It is possible tooverlook its attributes. If no useful objects can be found,new ones can be created. Existing objects can be editedor removed from the current object, or one can proceed toa sub catalogue of the objects components - if the objectis a compound one.3 OUTLOOKThe current implementation of EpicsOra is a basicfoundation to organize the work with several differentEPICS databases for several EPICS releases and a bignumber of IOC`s. Using Oracle as the basis to implementand store EPICS databases has the advantage to be ableto perform relations to other tools which have beenimplemented in Oracle – like the logbook. Besides thisalso the documentation of the databases is much easierand the conversion of databases on release changes issimplified.The next stage of this project will be to combine theOracle implementation with a graphical representation ofthe databases. This can be used for documentationpurposes, but also to specify for instance the prototypes.REFERENCES1. L.R.Dalesio, J.O.Hill, M.Kraimer etc. “TheExperimental physics and industrial control systemarchitecture: past, present, and future”, Proc. OfICALEPCS-93, Oct.18-23,1993, Berlin, Germany.2. E.Armstrong, C.Closkey, B.Linden, M.Pratt“Oracle7 (TM) Server Concepts Release 7.3 “, Belmont,California, USA, Nov. 1996.3. D.Brown, K.Chu, J.Magee “Oracle FormsDeveloper's Guide, Release 4.5”, Belmont, California,USA.462

The Use of ORACLE for Development and Maintenance of EPICS Databases

Abstract

Similar works

Full text

Available Versions

CERN Document Server