ADASS 2003 Conference Proceedings

The ALMA Common Software (ACS) is a CORBA-based framework that provides a common and homogeneous infrastructure for the whole ALMA software, from high-level data flow applications down to instrument control (Schwarz et al., 2004).

This paper focuses on ACS support for the development of Control System applications. In this domain, ACS provides a generic abstraction of hardware control and monitor points that is independent of the software underneath. This abstraction layer is coupled to the hardware using the DevIO (Device Input/Output) interface, based on the Bridge design pattern. Application developers have to implement DevIO classes that handle the details of the communication with the hardware.

ACS itself provides a default DevIO implementation which simply writes and reads into/from a memory location. Currently there are two other major DevIO implementations available: a CAN bus communication, used by ALMA, and a socket based implementation used by the Atacama Pathfinder EXperiment (APEX) project.

In spite of using different hardware and control electronics, the DevIO abstraction allows the ALMA and APEX projects to have the same device architecture down to the level of the DevIO implementation.

1. ACS Overview

ACS is located between the ALMA application software and other basic commercial or shared software on top of the operating systems and provides a generalized common interface between applications and the hardware in order to facilitate the implementation and the integration in the system of new hardware and software components.

ACS provides basic software services common to the various applications (like antenna control, correlator software, data pipelining) and consists of software developed specifically for ACS and as well of OS build and commercial device drivers. All code developed specifically for ACS is under the GNU Lesser General Public License. Commercial and off the shelf packages are subject to their specific license agreement.

ACS is designed to offer a clear path for the implementation of applications, with the goal of obtaining implicit conformity to design standards and maintainable software. The use of ACS software is mandatory in all ALMA applications, except when the requested functionality is not provided by ACS. Motivated exceptions (for example based on reuse considerations) have to be discussed and approved on a case by case basis.

The main users of ACS will be the developers of ALMA applications. The generic tools and GUIs provided by ACS to access logs, Configuration Database, active objects and other components of the system will be also used by operators and maintenance staff to perform routine maintenance operations.

2. High Level Architecture of an ACS Based Control System

3. Component/Property/Characteristic Design Pattern

Each Component has a number of Properties, which represent monitor and control points, e.g. electrical current, status, position etc. They provide asynchronous (using the callback mechanism) and synchronous retrieval and setting of values, monitors and alarms. There are primitive property types (long, double, etc.) and sequences of those primitive data types (longSeq, doubleSeq, etc.). They all can be read-only or read-write objects.

Components and Properties also have a set of Characteristics, which are static data, that are usually - but not necessarily - read from a configuration database, e.g. name, unit, minimum/maximum, etc.

Property interaction with the hardware is performed using the abstract DevIO interface.

4. DevIO - Generic Abstraction of Hardware

Properties - high-level abstraction of control/monitor points - provide the application with facilities to monitor and retrieve values from monitor points (get_sync, get_async), and to set the value of control points (set_sync, set_async), or to handle periodic telemetry logging and alarms. Internally, Properties use a DevIO implementation to access the actual hardware (Fig. 1). DevIO is a simple and generic abstraction of hardware monitor and control point, based on the Bridge design pattern. The hardware access points are abstracted with the DevIO parameterized (template) interface, which defines two methods:

These are the only abstract methods used by the Property to access the hardware. The implementations of the DevIO interface expose these two methods and hide the communication with the hardware (e.g. reading from and writing to hardware) and the conversion from raw values to engineer units and vice versa.

For example, the ACS high level code controlling a Power Supply is only aware of the SetPointCurrent control point and ReadbackCurrent monitor point. If the actual Power Supply is controlled via an Analog I/O board, the properties are configured with a DevIO capable of reading and setting control registries of the board. If this power supply is replaced by a new one controlled via a serial interface, only the DevIO implementation needs to be replaced.

**Figure 1:** DevIO class diagram.
$\begin{figure} \epsscale{0.8} \plotone{D8_f1.eps} \end{figure}$

5. Implementations of DevIO

Currently there are two other major DevIO implementations available: a CAN bus communication, used by ALMA, and a socket based implementation used by the Atacama Pathfinder EXperiment (APEX) project:

The Hexapod Telescope (HPT) of the U. of Bochum also uses ACS to interface the following hardware: Heidenhain Encoder board, Motor control unit, Shack-Hartmann sensing unit and Web camera.

Generic Abstraction of Hardware Control Based on the ALMA Common Software

Abstract:

1. ACS Overview

2. High Level Architecture of an ACS Based Control System

3. Component/Property/Characteristic Design Pattern

4. DevIO - Generic Abstraction of Hardware

5. Implementations of DevIO

References