Object Oriented Programming Techniques Applied to Device Access and Control A.Gotz, W.D.Klotz, J.Meyer ESRF, BP 220 F-38043 Grenoble Cedex FRANCE 1 Introduction standard for interfacing devices to computers. Although some attempts have been made at defining an industrial Device access and device control is one of the most impor­ standard none of them have succeeded (see [2]). This tant tasks of any control system. This is because control means that there are about as many ways to interface a implies obtaining information about the physical world by device to a computer as there are device suppliers. reading sensors and modifying the behaviour of the phys­ The device access problem would be simple if a single ical world by sending commands to actuators. At the standard were adopted for interfacing. In reality however European Synchrotron Radiation Facility (ESRF, this turns out to be too expensive because it involves extra ref. [1]) effort has gone into designing and implementing a development costs for the suppliers. model for device access and control using as much as possi­ ble the Latest ideas and methods of Software Engineering. One of the main contributions in recent years to Software 3 The Device Server Model Engineering has been in the field of Object Oriented Programming(OOP). Although the philosophy is not At the ESRF a unified model (called the device server new the refinement and application of this methodology model) has been developed to solve the problem of device on a wide scale is. At the ESRF a model for device access access and control. It is unified for two reasons — and control has been developed which is based on OOP methods. This model, called the device server model, • it presents a single interface for upper level applica­ is the topic of this paper. The device server model is writ­ tions to all kinds of devices, and ten entirely in C and is therefore portable. It depends on no other software and can be ported to any machine where • it defines the framework within which to implement there is a C compiler. Because the model is based on OOP device access and control for all devices. it presents a user-oriented view of the world as opposed to a software- or hardware-oriented view of the world. The model can be divided into a number of basic ele­ This paper will describe the device server model. It will ments - the device, the server, the Objects In C method­ describe the problem of device access and the advantages ology, the root class, the device class, resource database, of using OOP techniques to solve it. It will present the commands, local access, network access, and the applica­ model. The methodology used to implement OOP in the tion programmers interface. device server model called Objects In C (OIC) will be described. An example of a typical device server at the 3.1 The Model ESRF will be presented. The experience gained from the device server model will be discussed. The paper will con­ The basic idea of the device server model is to treat each clude with a discussion on how the device server model device as an object which is created and stored in a pro­ could be standardised to treat a wider range of problems. cess called a server. Each device is a separate entity which has its own data and behaviour. Each device has a unique name which iden­ 2 The Device Access Problem tifies it in network namespace. Devices are configured via resources which are stored in a database. Devices are The problem which the device server model is designed to organised according to classes, each device belonging to solve is a problem which every control system is faced with. a class. Classes are implemented in C using a technique The problem could be described as - how to provide access called Objects In C. All classes are derived from one root and control for all the physical devices which represent the class. The class contains a generic description of the de­ machine ? vice i.e. what actions can be performed on the device and Unfortunately there is no widely accepted industrial how it responds to them. The actions are made available 514 via commands. Commands can be executed locally or re- startup time) and then stored in a database. The first time motely (i.e. across a network). Network access to a device a client connects to a server it goes to the database to re­ and its commands is provided by an application pro­ trieve the server's address, after which it communicates grammers interface using a remote procedure call. directly with the server. 3.2 The Device 3.4 Objects In C The device is at the heart of the device server model. It The use of objects and classes in the device server model represents a level of abstraction which previously did not necessitates appropiate OOP tools. The natural choice exist. A device can be a physical piece of hardware (e.g. an would have been to use one of the many OOP languages interlock bit), an ensemble of hardware (e.g. a screen at­ which are available on the market today. If possible one tached to a stepper motor), a logical device (e.g. a taper), for which a standard exists or will exist (e.g. C++). The or a combination of all these (e.g. a storage ring). Each choice of a language is not independant of the develop­ device has a unique name. At the ESRF a three field name ment evironment however. The language chosen has to be space (consisting of DOMAIN/FAMILY/MEMBER) fully compatible with the development environment. At has been adopted. the ESRF the device access and control development envi­ The decision of what level of abstraction a device rep­ ronment consists of OS9, HP-UX, SunOS and the SUN resents depends on the requirements of the clients. At the NFS/RPC. Unfortunately there is no commercially avail­ ESRF these are the machine physicists. Devices should able OOP language compatible with this environment. model the clients view of the problem as closely as possi­ The only language which supports the above environment ble, Hardware dependencies should be hidden behind the is C. In order to use OOP techniques it was therefore device abstraction. For example if a corrector consists of necessary to develop a methodology in C, called Objects three independant powersupplies the client (assuming she In C (from here on OIC). The methodology developed is is a machine physicist) should only see a single device — implemented entirely in C and is closely modelled on the the corrector, and not three independant devices. widget programming model (ref. [3]). All devices are treated as having state. Each device OIC implements each class as a structure in C. Class has a list of commands which it understands. Before hierarchies are supported by subdividing a class structure any command can be executed the state machine gets into partial structures. Each partial structure representing checked to see if the command can be executed in the a super- or a sub-class. Each class requires a minimum of present state. The commands and the state machine are three files : implemented in the device's class. • a private include file describing the class and object structures, 3.3 The Server • a public include file defining the class and object Another integral part of the device server model is the types as pointers to structures and the class as an server concept. The server is a process whose main task is external pointer to the class structure, to offer one or many service(s) for clients who want to take • a source code file which contains the code implement­ advantage thereof. The server spends most of its time in a ing the class. wait-loop waiting for clients to demand its service(s). This division of labour is known as the client-server concept. The private include file is used to define constants and/or It exists in different flavours and is very common in modern variables which should not be visible to the outside world operating systems. (the inverse being true for the public include file). AH The adoption of this concept in the device server model functions implementing the class are defined to have static has certain implications. The server in the device server scope in C. This means that they cannot be accessed di­ model is there to serve one or many device(s) i.e. there rectly by any other classes or applications - they are only is one server per device but there can be many devices accessible via the method-finder or as commands. This per server. The exact configuration depends on the hard­ enforces code-hiding and reinforces the concept of en­ ware organisation, CPU charge, and the available memory. capsulation - a way of reducing coupling between soft­ The fact that there can be many devices per server means ware modules and making them immune to changes in that a single device should not monopolise the server for the class implementation. more than a pre-defined amount of time. Otherwise the OIC implements an explicit method-finder. The server is blocked and new or existing clients will not be method-finder is used to search for methods in a class or hi­ able to connect to the same or other devices served by that erarchy of classes. The method-finder enables methods to server. The server waits for clients by listening at a certain be inherited.