The Extremely Large Telescope (ELT) is a 39 meters optical telescope under construction in the Chilean Atacama Desert. The control software is under advanced development and the system is slowly taking shape for first light in 2028. ESO is directly responsible for coordination functions and control strategies requiring astronomical domain knowledge. Industrial contractors are instead developing the low-level control of individual subsystems. We are now implementing the coordination recipes and integrating the local control systems being delivered by contractors. System tests are performed in the ELT Control Model in Garching, while waiting for the availability of individual subsystems at the telescope. This paper describes the status of development for individual subsystems, of the high-level coordination software and of the system integration on the ELT Control Model (ECM), focusing on testing and integration challenges.
The long commissioning of the Adaptive Optics Facility (AOF) project has been completed shortly after this conference, providing AO correction to two Very Large Telescope (VLT) foci supported by an adaptive secondary mirror and four laser guide stars. Four AO modes are delivered: a Single Conjugate AO (SCAO) system for commissioning purpose, wide field and medium field Ground Layer AO (GLAO) for seeing improvement and narrow field Laser Tomography AO (LTAO) for ultimate performance. This paper intends to describe the implemented AO baseline and to highlight the most relevant results and lessons learned. In particular, it will address the control and reconstruction strategy, the wavefront sensing baseline and the online telemetry used to optimize the system online, estimate the turbulence profile and calibrate the misregistrations. Focusing on the LTAO mode, we will describe the tomography optimization, by exploring the reconstruction parameter space. Finally, on sky performance results will be presented both in terms of strehl ratio and limiting magnitude.
The ALMA Common Software (ACS), provides the infrastructure of the distributed software system of ALMA and other projects. ACS, built on top of CORBA and Data Distribution Service (DDS) middleware, is based on a Component- Container paradigm and hides the complexity of the middleware allowing the developer to focus on domain specific issues. The transition of the ALMA observatory from construction to operations brings with it that ACS effort focuses primarily on scalability, stability and robustness rather than on new features. The transition came together with a shorter release cycle and a more extensive testing. For scalability, the most problematic area has been the CORBA notification service, used to implement the publisher subscriber pattern because of the asynchronous nature of the paradigm: a lot of effort has been spent to improve its stability and recovery from run time errors. The original bulk data mechanism, implemented using the CORBA Audio/Video Streaming Service, showed its limitations and has been replaced with a more performant and scalable DDS implementation. Operational needs showed soon the difference between releases cycles for Online software (i.e. used during observations) and Offline software, which requires much more frequent releases. This paper attempts to describe the impact the transition from construction to operations had on ACS, the solution adopted so far and a look into future evolution.
The paper describes the introduction of a new automatized build and test infrastructure, based on the open-source software Jenkins1, into the ESO Very Large Telescope control software to replace the preexisting in-house solution. A brief introduction to software quality practices is given, a description of the previous solution, the limitations of it and new upcoming requirements. Modifications required to adapt the new system are described, how these were implemented to current software and the results obtained. An overview on how the new system may be used in future projects is also presented.
Code generation helps in smoothing the learning curve of a complex application framework and in reducing the
number of Lines Of Code (LOC) that a developer needs to craft. The ALMA Common Software (ACS) has
adopted code generation in specific areas, but we are now exploiting the more comprehensive approach of Model
Driven code generation to transform directly an UML Model into a full implementation in the ACS framework.
This approach makes it easier for newcomers to grasp the principles of the framework. Moreover, a lower
handcrafted LOC reduces the error rate. Additional benefits achieved by model driven code generation are:
software reuse, implicit application of design patterns and automatic tests generation. A model driven approach
to design makes it also possible using the same model with different frameworks, by generating for different
targets.
The generation framework presented in this paper uses openArchitectureWare1 as the model to text translator.
OpenArchitectureWare provides a powerful functional language that makes this easier to implement the correct
mapping of data types, the main difficulty encountered in the translation process. The output is an ACS
application readily usable by the developer, including the necessary deployment configuration, thus minimizing
any configuration burden during testing. The specific application code is implemented by extending generated
classes. Therefore, generated and manually crafted code are kept apart, simplifying the code generation process
and aiding the developers by keeping a clean logical separation between the two.
Our first results show that code generation improves dramatically the code productivity.
The ALMA Common Software (ACS) provides both an application framework and CORBA-based middleware
for the distributed software system of the Atacama Large Millimeter Array. Building upon open-source tools
such as the JacORB, TAO and OmniORB ORBs, ACS supports the development of component-based software in
any of three languages: Java, C++ and Python. Now in its seventh major release, ACS has matured, both in its
feature set as well as in its reliability and performance. However, it is only recently that the ALMA observatory's
hardware and application software has reached a level at which it can exploit and challenge the infrastructure
that ACS provides. In particular, the availability of an Antenna Test Facility(ATF) at the site of the Very Large
Array in New Mexico has enabled us to exercise and test the still evolving end-to-end ALMA software under
realistic conditions. The major focus of ACS, consequently, has shifted from the development of new features
to consideration of how best to use those that already exist. Configuration details which could be neglected
for the purpose of running unit tests or skeletal end-to-end simulations have turned out to be sensitive levers
for achieving satisfactory performance in a real-world environment. Surprising behavior in some open-source
tools has required us to choose between patching code that we did not write or addressing its deficiencies by
implementing workarounds in our own software. We will discuss these and other aspects of our recent experience
at the ATF and in simulation.
A high performance multicast model for the bulk data transfer mechanism in the ALMA (Atacama Large Millimeter
Array) Common Software (ACS) is presented. The ALMA astronomical interferometer will consist of at least 50 12-m
antennas operating at millimeter wavelength. The whole software infrastructure for ALMA is based on ACS, which is a
set of application frameworks built on top of CORBA. To cope with the very strong requirements for the amount of data
that needs to be transported by the software communication channels of the ALMA subsystems (a typical output data
rate expected from the Correlator is of the order of 64 MB per second) and with the potential CORBA bottleneck due to
parameter marshalling/de-marshalling, usage of IIOP protocol, etc., a transfer mechanism based on the ACE/TAO
CORBA Audio/Video (A/V) Streaming Service has been developed. The ACS Bulk Data Transfer architecture bypasses
the CORBA protocol with an out-of-bound connection for the data streams (transmitting data directly in TCP or UDP
format), using at the same time CORBA for handshaking and leveraging the benefits of ACS middleware. Such a
mechanism has proven to be capable of high performances, of the order of 800 Mbits per second on a 1Gbit Ethernet
network.
Besides a point-to-point communication model, the ACS Bulk Data Transfer provides a multicast model. Since the TCP
protocol does not support multicasting and all the data must be correctly delivered to all ALMA subsystems, a
distributer mechanism has been developed. This paper focuses on the ACS Bulk Data Distributer, which mimics a
multicast behaviour managing data dispatching to all receivers willing to get data from the same sender.
The ALMA Common Software (ACS) provides the software infrastructure used by ALMA and by several other telescope projects, thanks also to the choice of adopting the LGPL public license. ACS is a set of application frameworks providing the basic services needed for object oriented distributed computing. Among these are transparent
remote object invocation, object deployment and location based on a container/component model, distributed error, alarm handling, logging and events. ACS is based on CORBA and built on top of free CORBA implementations. Free software is extensively used wherever possible. The general architecture of ACS was presented at SPIE 2002. ACS has been under development for 6 years and it is midway through its development life. Many applications have been written
using ACS; the ALMA test facility, APEX and other telescopes are running systems based on ACS. This is therefore a good time to look back and see what have been until now the strong and the weak points of ACS in terms of architecture and implementation. In this perspective, it is very important to analyze the applications based on ACS, the feedback received by the users and the impact that this feedback has had on the development of ACS itself, by favoring the development of some features with respect to others. The purpose of this paper is to describe the results of this analysis and discuss what we would like to do in order to extend and improve ACS in the coming years, in particular to make application development easier and more efficient.
The ALMA Common Software (ACS) is a set of application frameworks built on top of CORBA. It provides a common software infrastructure to all partners in the ALMA collaboration. The usage of ACS extends from high-level applications such as the Observation Preparation Tool [7] that will run on the desk of astronomers, down to the Control Software [6] domain. The purpose of ACS is twofold: from a system perspective, it provides the implementation of a coherent set of design patterns and services that will make the whole ALMA software [1] uniform and maintainable; from the perspective of an ALMA developer, it provides a friendly programming environment in which the complexity of the CORBA middleware and other libraries is hidden and coding is drastically reduced. The evolution of ACS is driven by a long term development plan, however on the 6-months release cycle the plan is adjusted based on incoming requests from ALMA subsystem development teams. ACS was presented at SPIE 2002[2]. In the two years since then, the core services provided by ACS have been extended, while the coverage of the application framework has been increased to satisfy the needs of high-level and data flow applications. ACS is available under the LGPL public license. The patterns implemented and the services provided can be of use also outside the astronomical community; several projects have already shown their interest in ACS. This paper presents the status of ACS and the progress over the last two years. Emphasis is placed on showing how requests from ACS users have driven the selection of new features.
KEYWORDS: Databases, Java, Control systems, Visualization, Antennas, Software development, C++, Human-machine interfaces, Control systems design, Data modeling
The Atacama Large Millimeter Array (ALMA) is a joint project between astronomical organizations in Europe and North America. ALMA will consist of at least 64 12-meter antennas operating in the millimeter and sub-millimeter range, with baselines up to 14 km. It will be located at an altitude above 5000m in the Chilean Atacama desert.
The ALMA Common Software (ACS) provides a software infrastructure common to all partners and consists of a documented collection of common patterns and of components that implement those patterns.
The heart of ACS is an object model based on Distributed Objects (DOs), implemented as CORBA objects. The teams responsible for the control system development use DOs as the basis for components and devices such as an antenna mount control.
ACS provides common CORBA-based services such as logging, error and alarm management, configuration database and lifecycle management. A code generator creates a Java Bean for each DO. Programmers can write Java client applications by connecting those Beans with data-manipulation and visualization Beans.
ACS is based on the experience gained in the astronomical and particle accelerator domains, and reuses and extends proven concepts and components. Although designed for ALMA, ACS can be used in other new control systems, since it implements proven design patterns using state of the art, stable and reliable technology.
This paper presents the architecture of ACS and its status, detailing the object model and major services.
Access to the requested content is limited to institutions that have purchased or subscribe to SPIE eBooks.
You are receiving this notice because your organization may not have SPIE eBooks access.*
*Shibboleth/Open Athens users─please
sign in
to access your institution's subscriptions.
To obtain this item, you may purchase the complete book in print or electronic format on
SPIE.org.
INSTITUTIONAL Select your institution to access the SPIE Digital Library.
PERSONAL Sign in with your SPIE account to access your personal subscriptions or to use specific features such as save to my library, sign up for alerts, save searches, etc.