Information
We are currently investigating an issue with the editor of some pages. Please save your work and avoid to create new pages until this banner is gone.
ALMA Common Software Architecture
COMP-70.25.00.00-002-G-DSN
Version: G
Status: Draft
2009-04-15
Prepared By: |
|
|
Name(s) and Signature(s) |
Organization |
Date |
|
|
|
Approved By: |
|
|
Name and Signature |
Organization |
Date |
|
|
|
Released By: |
|
|
Name and Signature |
Organization |
Date |
|
|
|
Change Record
Table of Contents
1 Introduction5
1.1 Scope5
1.2 Overview6
1.3 Reference Architecture7
1.4 Reference Documents7
1.5 Glossary11
2 ACS Basic Architecture13
2.1 Overview13
2.2 Component Container model18
2.3 Deployment20
3 ACS Packages25
3.1 Development tools25
3.2 CORBA Middleware25
3.3 ACE25
3.4 ACS Component26
3.5 Configuration Database36
3.6 Event and Notification System41
3.7 Error System44
3.8 Logging System49
3.9 Time System53
3.10 ACS Container54
3.11 Daemons66
3.12 Parameters68
3.13 Tasks72
3.14 Serialization74
3.15 Archiving System78
3.16 Command System80
3.17 Alarm System83
3.18 Sampling85
3.19 Bulk Data87
3.20 User Interface Libraries and Tools90
3.21 Scripting support93
3.22 IDL Simulator93
3.23 ACS Application Framework95
3.24 ACS Installer96
3.25 Device Drivers97
3.26 Astronomical Libraries98
3.27 External Libraries98
4 Attributes100
4.1 Security100
4.2 Safety100
4.3 Reliability100
4.4 Performance100
5 Life cycle aspects101
5.1 Design requirements101
6 Requirements Compliance Table103
This document describes the architecture for the ALMA Common Software (ACS), taking as applicable the requirements specified in the ALMA Common Software Technical Requirements document and the ALMA Software Architecture.
This document provides a complete picture of the desired ACS functionality for the entire development phase, but individual concepts and features will be developed incrementally over a number of releases, according to the ALMA Common Software Development Plan . For each release, a detailed plan is developed, identifying the components to be added or revised. Development priorities will be discussed with the community of users during the planning phase of each release.
This issue of the Architecture takes into account the development of the ALMA Test Interferometer Control Software, the work done by the ALMA High Level Analysis team and the requests to ACS from higher level sub-systems as appearing in their respective documents and at the ACS planning meetings. In particular contains extensions that satisfy the needs of data flow software, pipeline, offline or proposal preparation.
With version A of this document, it has been decided to use ACS also as the underlying framework for the offline data reduction package (AIPS++). This requirement widens the scope of ACS and introducing new requirements that cover in particular the following areas:
This version of the ACS Architecture addresses many of these issues.
This document describes also some features that have not been implemented for ALMA until now and that possibly will not be implemented. It has been decided not to remove their description from the document for completeness and to make clear what is foreseen if any of these extensions needs to be implemented. These features are clearly identified in the text by the "Not implemented yet" or "Implementation not foreseen for ALMA" strings and by the usage of different fonts.
ACS is located in 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 builds and commercial device drivers. All code specifically developed for ACS is under the GNU Lesser General Public License (LGPL) . 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 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.
This document identifies the main packages that will be part of ACS and their high level interrelations. For each package, a section in this document respectively discusses the requirements to clarify them and presents an architectural concept.
Requirements are traced back to the ALMA Common Software Technical Requirements document whenever they are referenced. An ACS Requirements Compliance Table is maintained in the ACS Software Development Plan.
The concept illustrated here is based on the use of CORBA and takes into account knowledge of various control software projects based on CORBA in the astronomical and High Energy Physics communities, like SOFIA, GTC-Spain, ESRF-Grenoble, ANKA-Kalsruhe etc. A lot of experience has been accumulated in the past years of ACS development, in particular for what concerns the application of these concepts to high level applications and in particular pipeline, offline data reduction and observation preparation. A lot of discussions with the AIPS++ team have helped shaping ACS based on the requirements in these application domains. It has been an initial and explicit decision of the ALMA project to use CORBA technology and at the same time to share software rather than to re-invent it. It is up to documents like this to provide elements to confirm the initial choice of CORBA as adequate.
The reasons for using CORBA are in short: Object Orientation, support for distributed systems, platform independence, it is a communication standard, it provides a variety of services.
A reference layout for the system is provided by the ALMA Software Architecture, as required by. The Architecture of the Test Interferometer is described in the TICS Design Concept document.
For the purposes of this document a distributed architecture based on computers at the individual antennas and a number of central computers, connected by an high speed backbone , is assumed.
At both the antenna and the central control building there will be not only Ethernet LAN connectivity but also a Field-bus (the AMB) Field-bus] connected to various intelligent devices. The fact that the Antenna controller and all or part of these Devices is on Field-bus or LANs shall not make any difference in terms of the architecture proposed here.Pipeline, offline data reduction and other high level applications are also assumed to be distributed over many hosts, with the need or deploying CPU intensive applications dynamically based on the available resources.
This chapter contains one section per each ACS package, describing the features provided and its high level architecture.
The packages are described, looking at the package diagram in Chapter 2, starting from the lower layer and from left to right.
For some packages, just a brief description is given. In particular this applies to packages that are just the integration of off the shelf components.
The Requirements Compliance Table is now in the ACS Software Development Plan .
This table provides a trace of all requirements expressed in the applicable ALMA documents.