The ELT Control System can be divided into the Central Control System (CCS) and subsystems Local Control Systems (LCS)[1]. At the heart of the CCS we have the High-Level Coordination and Control (HLCC) software which offers a single interface to the telescope towards the operators and instruments and coordinates the telescope subsystems. HLCC interfaces to the Local Control Systems (LCS) via the respective subsystem Local Supervisors (LSV). The LSVs are then responsible for interfacing to the different LCSs converting from the astronomical and user domains into actions and measurements in the individual device's domain. Following celestial objects, i.e. tracking, is done on three ELT LSVs, the Main Structure (MS), the Dome and the PreFocal Station (PFS) LSVs. HLCC distributes the target information and the involved LSVs compute periodically the trajectory setpoints using the CCS's pointing engine for their respective devices. The tracking also considers a dynamic pointing origin, used to cope with the fact that the instruments might not have a perfectly aligned center of rotation. Pointing models that consider imperfections and physical effects are used for the MS and PFS LSVs. The timestamped setpoints are sent to the corresponding LCSs and feedback is gathered using deterministic channels.

As we all know too well, building up a collaborative community around a software infrastructure is not easy. Besides recruiting enthusiasts to work as part of it, mostly for free, to succeed you also need to overcome a number of technical, sociological, and, to our surprise, some political hurdles.The ALMA Common Software (ACS) was developed at ESO and partner institutions over the course of more than 10 years. While it was mainly intended for the ALMA Observatory, it was early on thought as a generic distributed control framework. ACS has been periodically released to the public through an LGPL license, which encouraged around a dozen non-ALMA institutions to make use of ACS for both industrial and educational applications. In recent years, the Cherenkov Telescope Array and the LLAMA Observatory have also decided to adopt the framework for their own control systems.The aim of the "ACS Community" is to support independent initiatives in making use of the ACS framework and to further contribute to its development. The Community provides access to a growing network of volunteers eager to develop ACS in areas that are not necessarily in ALMA's interests, and/or were not within the original system scope. Current examples are: support for additional OS platforms, extension of supported hardware interfaces, a public code repository and a build farm. The ACS Community makes use of existing collaborations with Chilean and Brazilian universities, reaching out to promising engineers in the making. At the same time, projects actively using ACS have committed valuable resources to assist the Community's work. Well established training programs like the ACS Workshops are also being continued through the Community's work.This paper aims to give a detailed account of the ongoing (second) journey towards establishing a world-wide open source collaboration around ACS. The ACS Community is growing into a horizontal partnership across a decentralized and diversified group of actors, and we are excited about its technical and human potential.

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.

ACS provides the infrastructure for the software of the Atacama Large Millimeter Array and other projects[1][2]. Using CORBA middleware, ACS supports the development of component-based software, from highlevel user interfaces down to the hardware device level. It hides the complexity of CORBA beneath an API that allows the application developer to focus on domainspecific programming. Although ACS, now at release 8, has been used operationally by the APEX radio telescope and at the ALMA Test Facility, the commissioning of ALMA in Chile brings major challenges: new hardware, remote operation and, most important, up-scaling from 2 to 60+ antennas[3][6]. Work now turns to scalability and improving the tools to simplify remote debugging. To further identify potential problems, the University of Eindhoven is formally analysing ACS. Meanwhile, new developments are under way, both to respond to newly identified needs of ALMA, and those of other projects planning to use ACS. Examples include the refactoring of the interface to the CORBA Notify Service, integration with the Data Distribution Service, generation of state machine code from abstract models and of Python binding classes from XML schema.

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 JacOR,B, 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.

The ALMA Common Software (ACS) is an application framework designed to provide a common and homogeneous software architecture and infrastructure, spanning the end to end needs of an Astronomical observatory, from the Telescope Control system to high-level data flow management. ACS offers, at the lower level, several basic services needed for object-oriented distributed computing like transparent remote object invocation, object deployment and location, distributed error, alarm handling, logging and events. On top of this it provides an application architecture based on the Component/Container paradigm that fosters sharing and reusing of software components. Although developed for the ALMA project, ACS is now used by several other projects worldwide, among which the Italian Sardinia Radio Telescope (SRT). Besides, there is an active community that shares ideas, concepts and actual software components. Major drivers for this diffusion were the choice of adopting the LGPL public license and the adoption of CORBA, a free but reliable and widely used middleware software. In this paper we present an overview of the main features of ACS, emphasizing in particular the role of INAF-OAT in this project.

An alarm system is a cornerstone service in every computer controlled environment. Its purpose is the notification of exceptional conditions in the system requiring an intervention from the staff. The specifications for the alarm system in the Alma Common Software (ACS) require not only that each alarm has to be shown to operators in a short time, but also that correlated alarms must be "reduced" and presented in compact form in such a way that operators are able to easily identify the root cause for an abnormal condition. In the development of ACS we always investigate the availability of adequate implementations before writing a service from scratch. Such an implementation, the CERN Laser Alarm System, developed for the Large Hadron Collider, was fulfilling and exceeding our requirements. We have therefore started a pilot collaboration project to verify the possibility of integrating Large Hadron Collider Alarm Service (LASER) into ACS. A test suite was developed to demonstrate that the full chain of events starting from the publication of new alarms from a set of sources to their representation in a GUI happened as expected. Particular attention was given to the reduction mechanism for its importance in helping the operators in finding the real cause of each problem in a short time. The project showed that it is possible to integrate two different software systems if they are written with well defined interface and have a similar infrastructure. In this paper we describe the modifications we introduce to integrate CERN LASER into ACS.

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 generic software interface simulator framework for Atacama Large Millimeter Array (ALMA) Common Software (ACS) provides ALMA developers with an easy means to create and configure the behaviour of interfaces that have been defined usin g Common Object Request Broker Architecture (CORBA) Interface Definition Language (IDL). ACS consists of a set of application frameworks built on top of CORBA and provides the glue which binds other ALMA software subsystems together [7]. In short, ACS provides an implementation of the component-container design pattern via CORBA. Using the simulation framework, one can choose to predefine the behaviour of a simulated component by embedding simple Python commands within a section of the XML-based ACS configuration database (CDB). The option to configure simulated components’ behaviour at run-time is also a possibility using a provided graphical user interfa ce (GUI) or application programming interface (API) executed within the context of an interactive Pytho n session. Additionally, if the means above have no t been utilized to setup the components’ behaviour th e framework will dynamically provide an implementation of the entire component with a randomized behaviour. This framework is especially useful to ALMA developers for two reasons. On one side it allows developers to test their own component, which is dependent upon other types of components that have been defined via IDL interfaces, but not yet implemented. On the other s ide this tool has proven itself to be quite valuabl e because it allows developers to connect clients suc h as graphical user interfaces to (simulated) components encapsulating hardware devices. Not only can the physical hardware devices be absent in this type of scenario, but the software representin g the hardware need not be available either. The en d result here is that clients and components can be d eveloped and tested in parallel completely independent of each other. This paper discusses the design, implementation, and current usage of the simulator framework within ALMA software as well as future improvements to be made.

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.

The Workstation Software Sytem (WSS) is the high level control software of the Italian Galileo Galilei Telescope settled in La Palma Canary Island developed at the beginning of '90 for HP-UX workstations. WSS may be seen as a middle layer software system that manages the communications between the real time systems (VME), different workstations and high level applications providing a uniform distributed environment. The project to port the control software from the HP workstation to Linux environment started at the end of 2001. It is aimed to refurbish the control software introducing some of the new software technologies and languages, available for free in the Linux operating system. The project was realized by gradually substituting each HP workstation with a Linux PC with the goal to avoid main changes in the original software running under HP-UX. Three main phases characterized the project: creation of a simulated control room with several Linux PCs running WSS (to check all the functionality); insertion in the simulated control room of some HPs (to check the mixed environment); substitution of HP workstation in the real control room. From a software point of view, the project introduces some new technologies, like multi-threading, and the possibility to develop high level WSS applications with almost every programming language that implements the Berkley sockets. A library to develop java applications has also been created and tested.

Workstation Software System is the control software of the Galileo Galilei Telescope. Developed more than 10 years ago for HP workstation, it needs now a general refurbishment to adopt the new hardware and software technologies. This paper will describe the development of this project from the linux operative system choices to the actual status of mixed control system passing throw a pro- totype realized under linux (Caproni et al. 2002).

The Italian National "Galileo" Telescope (Telescopio Nazionale "Galileo" - TNG) is a 3.5m telescope located at La Palma, in the Canary islands, which has seen first light in 1998. Available TNG subsystems include four first-generation instruments, plus adaptive optics, meteo and seeing towers; the control and data handling systems are tightly coupled allowing a smooth data flow while preserving integrity. As a part of the data handling systems, the production of a local "Archive at the Telescope" (AaT) is included, and the production of database tables and hard media for the TNG Long-Term Archive (LTA) is supported. The implementation of a LTA prototype has been recently terminated, and the implementation of its operational version is being planned by the Italian National Institute for Astrophysics (INAF). A description of the AaT and prototype LTA systems are given, including their data handling/archiving and data retrieval capabilities. A discussion of system features and lessons learned is also included, with particular reference to the issues of completeness and data quality. These issues are of particular importance in the perspective of the preparation of a national facility for the archives of data from ground-based telescopes, and its possible inclusion as a data provider in the Virtual Observatory framework.