Introduction

Why build a new object oriented control system? Object oriented device control is nothing new - a number of control systems in the accelerator world have been built based on it. The ESRF control system, TACO, has been based on object oriented device control from the beginning (cf. "Object Oriented Device Control", ICALEPCS 1991, Japan) and has proven that "object-orientedness" is well adapted to the problem of device control. What has changed since then is the emergence and general acceptance by industry of object oriented distributed models like CORBA and DCOM and new languages like Java or ANSI C++.

TACO was based on C, ONC/RPCs and device servers written in C using a method called OIC. Since then C++ has replaced OIC for writing device servers, signals and an asynchronous call have been added to TACO. TACO however lacks a true object-oriented API in C++ and/or Java. With the appearance of technologies like CORBA and DCOM it is now possible to define an object oriented API, in a language independant way, and automatically generate bindings for a number of languages e.g. C++ and Java. CORBA and DCOM offer a number of additional services for doing dynamic type management, naming, asynchronous calls, support for threads, transactions, etc. They also have the advantage of being supported on a large number of platforms (in the case of CORBA) and being well integrated in development environments (true for both). In order to profit from these advantages and from our own experience with object-oriented control we have decided to build a new object oriented control system which can be implemented in CORBA and/or DCOM and which offers all the features we consider lacking in TACO as it stands today e.g. a true object-oriented API, grouped calls, threads, events and monitors. The new control system will be called TANGO (for TACO New Generation objects).

This paper will present the basic philosophy, interface and architecture of TANGO. It will describe how device servers will be implemented, the concept of signals, the database, events, naming, and the overall system architecture in TANGO. It will conclude with a section on open issues, which still require discussion and a conclusion.

Basic Philosophy

Both CORBA and DCOM are based on an interface definition language (IDL). The interface definition language defines what an object is and what properties (attributes) and methods (actions) it has for the external world. Each object corresponds to a network interface at runtime. Objects are created in servers. Clients use the network interface to connect to objects and manipulate them as if they were local objects. CORBA/DCOM manage the network connection and exchange of data transparently for the client.

TANGO has adopted the philosophy that the number of network interfaces needed in the system be limited. Only those interfaces which can be considered as fundamental should be defined. These include system services and a basic device adapter. Objects which are not considered as fundamental e.g. a CCD camera, should be derived from a fundamental interface and wrapped locally on the client side. Network interfaces are therefore always of a fundamental type.

The advantage of this approach is that there are a limited number of network interfaces to implement. It is possible to address the problem of portability between different network object models i.e. CORBA and DCOM. Network programming is limited to a few fundamental interfaces and can therefore be hidden i.e. not everyone has to learn CORBA and/or DCOM. All derived objects offer the basic services implemented in the fundamental interfaces. New features can be added easily to all objects by adding them to one of the fundamental interfaces.

Although this approach is not the obvious way of using CORBA or DCOM we feel it is superior because of the advantages mentioned above. The only disadvantage of this approach is that wrapper classes have to be written for derived objects. This problem will be addressed by a tool, which will automatically generate the wrapper classes from a pseudo-IDL file.

Interface Definition

This section will introduce the fundamental TANGO interfaces. It will briefly describe them and what they do. For a full specification of the interfaces refer to the html documentation of the IDL file in appendix 1.

Device - is the fundamental interface for all control objects. A device can represent anything, hardware or software, which needs to be controlled. Its main purpose is to present a normalised programmable interface for clients to access, interrogate or change whatever needs to be controlled. Every device has a list of commands, attributes, signals and state. The commands are actions which can be performed on the device and which can have data attached to them. Commands can be executed synchronously or asynchronously. Attributes are data which can be get or set. Signals are a special case of attributes which have a fixed set of characteristics e.g. min, max, alarm, quality, description. Clients use the interface defined in IDL (directly or via a wrapper class) to access the Device. Devices are created and managed in processes called Device Servers. Clients can be in the same process space as the Device, in a different process on the same computer, and on a different computer. Higher level interfaces to Devices will be implemented in wrapper classes, which hide the low-level details of the Device network interface.

Callback - all actions, which can be executed on Device, can be done synchronously or asynchronously. In synchronous mode the client waits for the action to be completed before continuing. In asynchronous mode the client requests an action and then continues immediately without waiting. The client is informed of the action completion status via the Callback interface. Every client that does asynchronous requests is also a server. When the server informs the client that the action has completed it calls the Callback interface in the client passing it the status of the action and any return arguments. Each callback object has a handler method, which will be called every time new data arrive. A second method, handler_list, exists for handling grouped requests.

GroupDevice - is a local object (i.e. exists in client only) that groups a variable number of Devices into one object - GroupDevice. Using the GroupDevice the client can request an action on a number of Devices with a single call. The GroupDevice converts the request into multiple network requests in an optimized way. The client can add or remove Devices as needed. Synchronous and asynchronous mode is supported. GroupDevice only supports actions. To group Signals use GroupSignal.

GroupSignal - is a local object (i.e. exists in client only) that groups a variable number of Signals for a variable number of Devices into one object - GroupSignal. Using GroupSignal a client can read out a variable number of Signals for a variable number of Devices with a single call. The GroupSignal converts the request into multiple network requests in an optimized way. The client can add or remove Signals as needed. All requests are synchronous.

Monitor - is a system network object, which allows a client to register its interest in a range of events and be informed of any changes. Events can range from periodic polling to change of value to change of state to device specific events. Monitors are system wide. The client posts its request to the first Monitor it finds. The device/signal and the type of event must be specified. Clients can add and delete events as needed. The Monitor informs the client of new events via the Consumer interface.

Consumer - is the client interface that receives events from Monitors. It has the same role as the Callback interface except that it accepts event-related information e.g. event type, id, device, etc.

DataBase - is the network interface to the database. The database is the general system repository for all permanent information. In TANGO the database is used to store device names and resources. Resources can be static or dynamic. The Database interface supports getting and setting of resources. A number of basic data types and arrays of basic data types are supported. Device attributes can be made permanent by storing them as resources in the database.

TclAutomate - is a network interface for executing Tcl scripts. Tcl is a gluing language developed originally by John Ousterhout (cf. http://www.tclconsortium.com). The Tcl language has been extended to support the TANGO interfaces. Clients can download Tcl scripts which manipulate devices and start them remotely.

Server - is a generic interface to all servers. It allows servers to be started and stopped or simply interrogated remotely.

Scan - one of the main uses of the control system is to measure variations as a function of time or of another parameter - also know as scanning. Scanning is often done by a high-level tool, which talks to a collection of devices via the network. This has the disadvantage that the network limits the scanning speed. In order to overcome this limitation and to be able to achieve the performance of the hardware TANGO offers a low-level interface (Scan) for scanning any property of any device. The Scan interface is derived from Device and can be used to scan any group of properties. The scan is executed locally (in the device server) and is therefore not limited by the hardware. A high-level tool (or another Device) can be used to set-up scans across multiple Devices. Hardware synchronisation can be used to synchronise across cards/CPUs.

Device Servers

TANGO Device objects are created and served in processes called Device Servers as was the case for TACO. TANGO Device Servers differ from TACO Device Servers in that they are inherently multi-threaded. There will be a minimum of two threads always - one thread dedicated to handling network requests and one thread for executing client requests. Different threading models will be supported for client requests viz. one-thread-for-all, one-thread-per-request, or one-thread-per-object. At startup time the Device Servers interrogate the static database to find out which devices belonging to which classes they should serve. Devices are created by executing the create() method of a local DeviceFactory object. The DeviceFactory will create the Device of the required class in a separate thread and execute their initialise() method. After that the main thread of the DeviceServer goes to sleep waiting for network requests. Devices can however start a separate thread which does some active processing while the main thread is sleeping on the network.

It is planned to support the writing Device Servers in C++ and Java on the following platforms : Linux/x86. Linux/m68k, Windows/NT, Windows/95, Solaris, HP-UX, and VxWorks.

Signals

All Device data, which is not attached to an action will be represented as Signal. Signals are Properties which have a standard set of Characteristics e.g. min, max, low alarm, high alarm, description, units, scale factor, etc. Exchanging data in a standardised format means generic clients which can read, display and interpret all data. Signals are not intended to be addressable objects. They always belong to a Device and can be accessed only via the Device interface. An exception to this is the GroupSignal interface.

Database

TANGO will support a static database for storing Device resources. Resources are any ASCII string. Resources can be retrieved as binary data. Basic C types and arrays are supported. The database is also used to store the list of all Devices and DeviceServers per host required for startup.

Events

Events are asynchronous information, which are sent to clients who have registered their interest. TANGO supports events for doing periodic updates, on state change, on value change, and device specific events. Clients do not receive unsolicited events. A client registers its interest in an event by sending a request to a Monitor object. The client has to create a Consumer object for receiving. When an event occurs the client is informed by triggering the handler() method in the Consumer object. Events are sent via a reliable communication channel. The client is informed of a breakdown in the communication channel e.g. via a heartbeat.

Name Serving

Every Device in a TANGO control system has a name, which is unique. The Device name is used by clients to identify Devices. TANGO will (like TACO) support multiple namespaces. A namespace corresponds to a facility. A single client can talk to Devices in multiple facilities e.g. accelerator + beamlines. TANGO Device names will consist of up to 5 fields - [protocol://facility/]domain/family/member. Protocol can be rpc (for old TACO Devices served by RPC Device Servers) or iiop (for new TANGO Devices served by CORBA Device Servers). Facility identifies the name of the host on which the static database server is running. Domain, family and member identify the Device within the facility e.g. TL1/PS-D/D. A Device has Signals. Signal names are formed by adding a sixth field to the full name i.e. [protocol://facility/]domain/family/member/signal. Signals are however not objects and have to be accessed via a Device object or a (local) GroupSignal object.

System Architecture

System architecture refers to the overall organisation of a TANGO control system, how many and which system processes have to run, how to bootstrap servers, how clients create a connection to servers. The number of system processes in a TANGO system will be kept to a minimum. TANGO will not have a Manager nor Message server (as was the case for TACO). TANGO will rely solely on the Database server for bootstrapping servers and clients. All information necessary for this will be stored in the database in system tables. Starting a TANGO system will therefore be reduced to starting the Database server. The database will be configured with a list of all servers and clients to start at startup time. The Database or an independent tool can then be used to start all other (device) servers and clients. An open issue today is whether to integrate the CORBA NameServer or not into TANGO. If we decide to use the NameServer then it has to be started with the Database server. The advantage of this is the NameServer can be used to discover the database. If we decide not to use the NameServer then a solution for the Database network address has to be found e.g. pass address via environment variables. Once the servers and clients are running the database is not accessed anymore unless the server needs to store/retrieve resources or the server is restarted and the client needs to rebuild the connection.

Backwards Compatibility / Gateway

In order to ensure a smooth integration of TANGO into running TACO control systems TANGO has to offer backwards compatibility to TACO. This will be achieved by a Gateway which implements the TANGO fundamental interfaces (Device, Monitor, Database) on top of TACO RPC dev_putget() type calls. Using the Gateway it will then be possible to write clients in C++ or Java, which use the TANGO interface to talk to a TACO control system.

Forwards Compatibility

It is now planned to support forwards compatibility i.e. the possibility to access TANGO Devices from TACO. This will be done using a TACO-TANGO Gateway to translate dev_putget() calls into TANGO Command methods. Although this will add an overhead during execution experience shows that it is small. The gateway will support all TANGO features which have an equivalent in TACO. New features (e.g. Monitors, Scans, threads, C++, Java) will only be supported if there is a real need for them i.e. a client cannot use TANGO directly.  This way a the old TACO C API will be work even for new device servers written in CORBA or DCOM.

Java Beans / Active X

In addition to a C++ and Java interface (generated from the IDL file) TANGO will support Java Beans for doing graphical components. A Java Bean will be provided for each of the fundamental interfaces (Device, Monitor and Database). These Beans can then be used in a Bean Box (or other suitable Java builder) to build graphical applets or applications.

For those applications running in a pure Windows environment support for Windows ActiveX components will be provided either via Java Beans-Active X bridge or via an Active X which implements the TANGO API directly. An Active X which implements the TANGO API on top of TACO DSAPI exists already.

Open Issues

Some open issues today are :

1. NameServer vs. Database - should the CORBA NameServer be used to associate network addresses with names? Or should the TANGO Database be used for this (as was the case in TACO)? The advantage of using the CORBA NameServer is that CORBA offers a bootstrapping method for connecting to the NameServer and it is compatible with other CORBA object browsers. The disadvantage is that it can only store network addresses but no additional information like class name, version etc. can be stored. A solution might be to combine the CORBA NameServer and the Database server in one server which supports both interfaces.
2. Events - should the Monitor use the CORBA Event service? The ORB chosen (ORBacus aka Omnibroker) supports the Event service and could be an efficient way to distribute events to clients. However the Event service is CORBA specific and will not work with DCOM servers/clients. Needs looking into.
3. DCOM vs. CORBA - why want to do an implementation in both*? The main reason is that it is not clear which technology will dominate in the future. Therefore instead of making a decision at an early stage with the associated risk of choosing the "wrong" one we prefer to support or at least explore both so that in the future we can switch if necessary.

Useful Links

1. TACO home page -  http://www.esrf.fr/Infrastructure/Computing/SoftwareEngineering/TACO
   
2. CORBA consortium (OMG) home page - http://www.omg.org
   
3. COM and DCOM home pages - http://www.microsoft.com/com
   
4. ORBacus (Omnibroker) home page - http://www.ooc.com/ob
   
5. Java home page - http://www.javasoft.com