Nielsen, J S

Nielsen, K T

Worm, T

CERN Document Server

ConSys – A NEW HIGHLY OBJECT ORIENTED CONTROL SYSTEMK. T. Nielsen+, J. S. Nielsen, T. Worm,ISA, Institute for Storage Ring Facilities in Aarhus, University of Aarhus, Denmark1 ABSTRACTThe ConSys control system1,2 is developed for controlof the storage ring facilities at ISA. A strong object-oriented approach has been used resulting in a highlyflexible and modular design, where front-end and clientcomputers have identical core software. All machinedependent information is stored in a database. The resultis a site and machine independent system that is easy tomaintain. The control system is implemented on PC´srunning Windows NT. It follows the standard model, aswell as the publisher/subscriber model.2 THE ABSTRACT MODELA very limited set of object types defines andimplements the core functionality of the control system:Devices are the interface between the controlled hardwareand the control system. Data servers register at devicesand serve as data transmitters between the device and theclients. Before a client can access parameters on thecontrol system it must send a data request to the system.The data request must include an address specifying theparameter. For all data in the control system, a ConSysdata object is used as base class. All data transmittedbetween computers by the transport object must bedescendants of the ConSys data object.2.1 ParametersAn important feature of a control system is the basicdata unit used in system. Many control systems uses a fulldevice data block as the basic access unit3, resulting in alarge number of objects types to maintain. However, forsimplicity a small number of basic object types isdesirable. These may afterwards be combined into logicalgroups reflecting the hardware structure. When theoperators are operating the machine, they tend not tooperate on say a full power supply, but on for example thecurrent setting. The ConSys control system acts on singleparameters. A parameter may be a current setting on amagnet, or an on/off bit for a power supply. As the valueof a parameter is transmitted as a descendant object of thedata value object, a great flexibility in the contents of aparameter is possible. Most parameters are of simpletypes, like floating and binary values, but could as well bea full spectrum from a data acquisition. As a rule theparameters on the system tend to be as fine-grained asfeasible.2.2 AddressingA central concept in the control system is thegeneralised address space. As the access method of theindividual hardware devices may vary greatly, the controlsystem must provide a uniform and flexible way ofaccessing parameters. To create a homogeneous controlsystem it is important to hide the details of parameteraccess, and only make use of this knowledge in thedevices. The address object contains the informationneeded to access a parameter in the device. The address isfully qualified; there is no need for more information todetermine the location of a parameter. The base addressobject only contains information about the computer andthe device where the parameter is located. Any additionalinformation is provided by descendant classes.2.3 DevicesThe device object provides the abstraction between thehardware instrument drivers and the control system. Thedevice includes the real time database with the parameterstorage needed by the givendevice. The base objectdefines abstract methods forreading and writing. Anaddress object included withthese methods locates theparameter in the device. Theobject furthermore includesan abstract method forparameter subscription.Data servers may call thismethod in order to registerfor subscription at thedevice. The device signalsthe registered data serverswhenever data has changedin the device.An important concept is avirtual device - a devicewithout direct connection tohardware. In the simplest case, a virtual device is just astorage device for persistent information. A moreadvanced use of the virtual device is intelligent datahandling - that might be automation of operation or asspecial conversions between say physical parameters anddirect controls. In the lather case the virtual device utilisesthe ability to connect to any parameter on the controlsystem, just as any other client application on the system.ApplicationClientData ServerDeviceNT Device Drivernnnn10, 10, 1Transport1Figure 1: ConSys ObjectrelationsInternational Conference on Accelerator and Large Experimental Physics Control Systems87International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italy2.4 Data ServersObtaining and transmitting data to the client is done bydata servers. A data server may register itself at a device.The device will signal the data server when data mayhave changed. It is the responsibility of the data server todecide whether the data should be sent to the client or not.When a writing operation takes place, it is theresponsibility of the data server to ship the data to thedevice. The data server may also act as an agent for theclient, combining information from one or more deviceson behalf of the client. As the data server does not assumea connection to a device, a data server may start otherdata servers up or act as a client to do complicated tasks.As opposed to a device, a data server provides nopersistent storage.To provide the control system with initialisationinformation about the data servers a data request object isused. The data request includes information about thetype of data server to load, and from which library to getit. The object may also contain a reference to an instanceof the address object. This allows the data server to accessa device. The request also contains a handle that uniquelyidentifies data received and transmitted by the data server.Descendant objects may add additional information usedby the data server, such as criteria for transmission of datato the client.2.5 The ConSys ClientApplications interface to the control system through theConSys client object. This object provides a small butpowerful set of methods to be used by the client programto gain access to the control system data. On creation theclient is supplied with a data request. Based on the datarequest the client will create all necessary connections.For most applications only two methods provided by theclient is needed - one for writing data to the system andone to handle data arriving from the control system.Internally in ConSys the data servers and devices areimportant users of the client object.2.6 Data objectsThe base of all data transmitted in the control system isthe ConSys data object. Although the object can betransmitted in the system, it is the two descendant objectsthat are used. The first descendant object is a messageobject, which acts as base object for all messages. Theother descendant is the data value object. This object isthe base object for all parameter information exchangedin the system. In order to distinguish the origin of the datain the control system, the data value objects have a uniquehandle attribute defined by the client in the request. Alldata arriving as a result of a given request is tagged withthis handle. The handle is especially used when therequest results in access to more than one parameter.Likewise data sent to the control system must include ahandle in order to let the system send the data to thecorrect destination.In figure 1 the relations between the important objectsin ConSys control system are drawn. An application maycreate as many client objects as it wants, depending onthe structure of the application. Each client creates atransport layer, which in turns creates a single data server.The specific type of the data server depends on therequest specification. The data server may create as manyhelper data servers or new client objects as it needs. Itmay also connect to a single device. A device may createas many client objects it wants. If the device is a virtualdevice it will not connect to a device driver. If the deviceis controlling hardware, it connects to a single devicedriver. Figure 1 illustrates the fact that the control systemis its own best client, with data servers and devices actingfreely as clients on the system in parallel with accessfrom other applications.3 IMPLEMENTATIONIn order to take advantage of the huge amount of goodand cheap software and hardware available for PC‘s,Windows NT is used as platform for ConSys. To reducedevelopment time and cost the ConSys only runs on theWindows NT platform. Note that this is true for front-endcomputers as well as client computers. Having chosen thesame operating system on all machines has given apossibility for a very high degree of symmetry in thesystem. In fact it has been possible to use the same corecode on front-ends and clients, which has greatlyincreased simplicity, reliability and flexibility of thesystem.To a large extent ConSys uses the possibility to setprocess and thread priorities. As the overhead of havingmany threads running on a system is insignificant, thecontrol system uses a large number of threads at manydifferent priorities to optimise the response time. Theresult is that the system can take a very high load beforethe user starts to see a significant performance penalty.3.1 Name spaceAn identification triplet defines parameters in logicallyrelated groups: machine.name.sub-name. The machineidentifies the accelerator to which the parameter belongs.The name identifies a group of related parameters, i.e.parameters controlling a given piece of equipment. Thesub-name identifies the individual parameters for thepiece of equipment. Although the triplet usually reflectsthe hardware structure, there are no assumptions made bythe control system.3.2 Establishing a data connection.For accessing single parameters, simple requests foreach data type exist. Requests include an address andinformation needed to dynamically create the associated88data server. To access more than one parameter from asingle client a packet request is implemented. The packetrequest has a list of requests. This list can contain requestof any type - for example other packet requests to createnested structures. The packet request is closely related tothe packet data server. The packet request specifiescreation of a packet data server. When this special dataserver is created it splits the request list into separatepacket requests depending on destination front-end. Foreach of these single front-end requests a new client iscreated. If one of these clients detects a request containingrequests for the local computer it creates the specifieddata servers. All other clients contain request for remotecomputers. These clients create a transport to thespecified machine and send the request to the ConSyskernel on that machine. On the remote machine, yetanother packet server is created, now only containinglocal requests on the remote machine. This packet servercollects data from the local data servers on the front-endand routes them back to the original data server on thecalling machine.ConSys data is transmitted between computers using aninstance of the transport object. The base transport objectonly has a few general methods used to handle thecommunication. It can be created in two modes - either asa server or as a client. When a client in ConSys wantsaccess to a remote computer, it creates an instance of thetransport in client mode with a specification of the nameof the remote computer. During the creation, the transportobject tries to establish a connection to the specifiedcomputer. On a successful connection, ConSys dataobjects can now be send trough the transport using itsserialisation operators for reading and writing.3.3 DatabaseAll machine dependent information for the controlsystem is stored in an ODBC compliant database – at ISAMicrosoft SQL server 7.0 is used. For performancereasons the object-oriented structure of ConSys cannot berepresented directly in a relational database, insteadgeneralised tables with free fields are used.In general, the database tables used to construct ConSysobjects of a given type contain the attributes of the baseobject and a number of generalised fields used for theconstruction of descendants to the base object. Helpertables in the database describe the actual use of thegeneral fields for a given object. With the helper tables, ithas been possible to develop an object oriented databaseeditor reflecting the object structure of ConSys.As an example, a parameter definition in the parametertable includes the informations needed for thecorrespondent address object: An address type fieldidentifies the address object associated with theparameter, computer name and device identificationnumber fields contain information needed to initialise thebase part of the address object. The additional informationneeded to initialise the given address object is stored in aseries of general-purpose integer and string fields in theparameter table. The actual use of these fields is describedin a helper table for the address objects in the controlsystem.The parameter table furthermore specifies theinterpretation type of the parameter. The interpretationtype is a combination of three related parameter attributes- the data type, the conversion type and the display type.The data type identifies the data objects known by thecontrol system. Each data object type has at least oneconversion object type and one display type. The ConSysdevices on the front-ends may utilise the conversionobjects to convert between native values and physicalvalues. The display type gives the client applicationknowledge on how to display the parameter data. Thevalid combinations of data types, conversion types anddisplay types are hardwired into the ConSys code andreflected in the database by a table maintained by theprogrammers.3.4 Dynamic object loadAn important mechanism in the control system is theability to dynamically create instances of objects. Bysupplying the system with the name of the class and thedynamic link library, the system is able to create aninstance of the class. This method is used to create thevarious components of the control system. The transportlayer, database interface, and the devices are created atstart-up of the control system. Likewise the data serversare dynamically created as specified by the client request.This ability to dynamically add and configure the systemwithout re-compilation has proved a great advantage.4 CONCLUSIONThe object-oriented approach has resulted in a highlyflexible and modular design, where front-end and clientcomputers have identical core software. The limitednumber of base objects, the central database for allmachine dependent information and the possibility ofloading and creating object instances dynamically haslead to a site and machine independent control systemthat is easy to maintain.REFERENCES [1] J.S.Nielsen K.T.Nielsen and T.Worm: “ConSys – Anew control system for ASTRID and ELISA”,TUP46G, Proc. From the 6'th European ParticleAccelerator Conference, EPAC98, Stockholm 1998, p1679.[2] www.isa.au.dk/ConSys/[3] Jie Chen, Graham Heyes, Walt Akers, Danjin Wu,Wiliam A. Watson III: “CDEV: An Object-OrientatedClass Library for Developing Device ControlApplications”, ICALEPCS 1996 proceedings+   Now at Scanvaegt International A/S89

ConSys: A New Highly Object Oriented Control System

Abstract

Similar works

Full text

Available Versions

CERN Document Server