The Cherenkov Telescope Array (CTA) will be the next-generation ground-based instrument for detecting veryhigh energy gamma rays. It will consist of roughly 100 telescopes of different sizes and designs. In addition, a variety of auxiliary instrumentation will be part of the array. The Observation Execution System (OES) is the software system in charge of operating and monitoring all telescopes and devices, applying short-term observation schedules depending on the hardware status and environmental conditions and handling the data. Motivated by the wealth of tasks to accomplish and requirements to fulfil, a software development procedure is conceived for the development of OES. Part of this development process is the application of software testing procedures. These procedures range from unit tests up to system tests and stress tests. In this contribution, the software development process and the application of static and dynamic code analysis tools are described.
The Cherenkov Telescope Array (CTA) will be the next generation ground-based observatory for gamma-ray astronomy at very-high energies. CTA will consist of two large arrays with 118 Cherenkov telescopes in total, deployed in the northern and southern hemispheres. The Observation Execution System (OES) provides the means to execute observations and to handle the acquisition of scientific data in CTA. The Manager and Central Control (MCC) system is a core element in the OES system that implements the execution of observation requests received from the scheduler sub-system. This contribution provides a summary of the main MCC design features and of the plans for prototyping.
Today the scientific community is facing an increasing complexity of the scientific projects, from both a technological and a management point of view. The reason for this is in the advance of science itself, where new experiments with unprecedented levels of accuracy, precision and coverage (time and spatial) are realised. Astronomy is one of the fields of the physical sciences where a strong interaction between the scientists, the instrument and software developers is necessary to achieve the goals of any Big Science Project. The Cherenkov Telescope Array (CTA) will be the largest ground-based very high-energy gamma-ray observatory of the next decades. To achieve the full potential of the CTA Observatory, the system must be put into place to enable users to operate the telescopes productively. The software will cover all stages of the CTA system, from the preparation of the observing proposals to the final data reduction, and must also fit into the overall system. Scientists, engineers, operators and others will use the system to operate the Observatory, hence they should be involved in the design process from the beginning. We have organised a workgroup and a workflow for the definition of the CTA Top Level Use Cases in the context of the Requirement Management activities of the CTA Observatory. Scientists, instrument and software developers are collaborating and sharing information to provide a common and general understanding of the Observatory from a functional point of view. Scientists that will use the CTA Observatory will provide mainly Science Driven Use Cases, whereas software engineers will subsequently provide more detailed Use Cases, comments and feedbacks. The main purposes are to define observing modes and strategies, and to provide a framework for the flow down of the Use Cases and requirements to check missing requirements and the already developed Use-Case models at CTA sub-system level. Use Cases will also provide the basis for the definition of the Acceptance Test Plan for the validation of the overall CTA system. In this contribution we present the organisation and the workflow of the Top Level Use Cases workgroup.
The ASTRI mini-array, composed of nine small-size dual mirror (SST-2M) telescopes, has been proposed to be installed at the southern site of the Cherenkov Telescope Array (CTA), as a set of preproduction units of the CTA observatory. The ASTRI mini-array is a collaborative and international eﬀort carried out by Italy, Brazil and South Africa and led by the Italian National Institute of Astrophysics, INAF. We present the main features of the current implementation of the Mini-Array Software System (MASS) now in use for the activities of the ASTRI SST-2M telescope prototype located at the INAF observing station on Mt. Etna, Italy and the characteristics that make it a prototype for the CTA control software system. CTA Data Management (CTADATA) and CTA Array Control and Data Acquisition (CTA-ACTL) requirements and guidelines as well as the ASTRI use cases were considered in the MASS design, most of its features are derived from the Atacama Large Millimeter/sub-millimeter Array Control software. The MASS will provide a set of tools to manage all onsite operations of the ASTRI mini-array in order to perform the observations speciﬁed in the short term schedule (including monitoring and controlling all the hardware components of each telescope and calibration device), to analyze the acquired data online and to store/retrieve all the data products to/from the onsite repository.
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 Cherenkov Telescope Array (CTA) will be the next-generation ground-based observatory using the atmospheric Cherenkov technique. The CTA instrument will allow researchers to explore the gamma-ray sky in the energy range from 20 GeV to 300 TeV. CTA will comprise two arrays of telescopes, one with about 100 telescopes in the Southern hemisphere and another smaller array of telescopes in the North. CTA poses novel challenges in the field of ground-based Cherenkov astronomy, due to the demands of operating an observatory composed of a large and distributed system with the needed robustness and reliability that characterize an observatory. The array control and data acquisition system of CTA (ACTL) provides the means to control, readout and monitor the telescopes and equipment of the CTA arrays. The ACTL system must be flexible and reliable enough to permit the simultaneous and automatic control of multiple sub-arrays of telescopes with a minimum effort of the personnel on-site. In addition, the system must be able to react to external factors such as changing weather conditions and loss of telescopes and, on short timescales, to incoming scientific alerts from time-critical transient phenomena. The ACTL system provides the means to time-stamp, readout, filter and store the scientific data at aggregated rates of a few GB/s. Monitoring information from tens of thousands of hardware elements need to be channeled to high performance database systems and will be used to identify potential problems in the instrumentation. This contribution provides an overview of the ACTL system and a status report of the ACTL project within CTA.
The Italian National Institute for Astrophysics (INAF) is leading the Astrofisica con Specchi a Tecnologia Replicante Italiana (ASTRI) project whose main purpose is the realization of small size telescopes (SST) for the Cherenkov Telescope Array (CTA). The first goal of the ASTRI project has been the development and operation of an innovative end-to-end telescope prototype using a dual-mirror optical configuration (SST-2M) equipped with a camera based on silicon photo-multipliers and very fast read-out electronics. The ASTRI SST-2M prototype has been installed in Italy at the INAF “M.G. Fracastoro” Astronomical Station located at Serra La Nave, on Mount Etna, Sicily. This prototype will be used to test several mechanical, optical, control hardware and software solutions which will be used in the ASTRI mini-array, comprising nine telescopes proposed to be placed at the CTA southern site. The ASTRI mini-array is a collaborative and international effort led by INAF and carried out by Italy, Brazil and South-Africa. We present here the use cases, through UML (Unified Modeling Language) diagrams and text details, that describe the functional requirements of the software that will manage the ASTRI SST-2M prototype, and the lessons learned thanks to these activities. We intend to adopt the same approach for the Mini Array Software System that will manage the ASTRI miniarray operations. Use cases are of importance for the whole software life cycle; in particular they provide valuable support to the validation and verification activities. Following the iterative development approach, which breaks down the software development into smaller chunks, we have analysed the requirements, developed, and then tested the code in repeated cycles. The use case technique allowed us to formalize the problem through user stories that describe how the user procedurally interacts with the software system. Through the use cases we improved the communication among team members, fostered common agreement about system requirements, defined the normal and alternative course of events, understood better the business process, and defined the system test to ensure that the delivered software works properly. We present a summary of the ASTRI SST-2M prototype use cases, and how the lessons learned can be exploited for the ASTRI mini-array proposed for the CTA Observatory.
The Cherenkov Telescope Array (CTA) project is an initiative to build two large arrays of Cherenkov gamma- ray telescopes. CTA will be deployed as two installations, one in the northern and the other in the southern hemisphere, containing dozens of telescopes of different sizes. CTA is a big step forward in the field of ground- based gamma-ray astronomy, not only because of the expected scientific return, but also due to the order-of- magnitude larger scale of the instrument to be controlled. The performance requirements associated with such a large and distributed astronomical installation require a thoughtful analysis to determine the best software solutions. The array control and data acquisition (ACTL) work-package within the CTA initiative will deliver the software to control and acquire the data from the CTA instrumentation. In this contribution we present the current status of the formal ACTL system decomposition into software building blocks and the relationships among them. The system is modelled via the Systems Modelling Language (SysML) formalism. To cope with the complexity of the system, this architecture model is sub-divided into different perspectives. The relationships with the stakeholders and external systems are used to create the first perspective, the context of the ACTL software system. Use cases are employed to describe the interaction of those external elements with the ACTL system and are traced to a hierarchy of functionalities (abstract system functions) describing the internal structure of the ACTL system. These functions are then traced to fully specified logical elements (software components), the deployment of which as technical elements, is also described. This modelling approach allows us to decompose the ACTL software in elements to be created and the ow of information within the system, providing us with a clear way to identify sub-system interdependencies. This architectural approach allows us to build the ACTL system model and trace requirements to deliverables (source code, documentation, etc.), and permits the implementation of a flexible use-case driven software development approach thanks to the traceability from use cases to the logical software elements. The Alma Common Software (ACS) container/component framework, used for the control of the Atacama Large Millimeter/submillimeter Array (ALMA) is the basis for the ACTL software and as such it is considered as an integral part of the software architecture.
ASTRI (Astrofisica con Specchi a Tecnologia Replicante Italiana) is a flagship project of the Italian Ministry of Research and led by the Italian National Institute of Astrophysics (INAF). One of its aims is to develop, within the Cherenkov Telescope Array (CTA) framework, an end-to-end small-sized telescope prototype in a dual-mirror configuration (SST-2M) in order to investigate the energy range E ~ 1-100 TeV. A long-term goal of the ASTRI program is the production of an ASTRI/CTA mini-array composed of seven SST-2M telescopes. The prototype, named ASTRI SST-2M, is seen as a standalone system that needs only network and power connections to work. The software system that is being developed to control the prototype is the base for the Mini-Array Software System (MASS), which has the task to make possible the operation of both the ASTRI SST-2M prototype and the ASTRI/CTA mini-array. The scope of this contribution is to give an overview of the hardware and software architecture adopted for the ASTRI SST- 2M prototype, showing how to apply state of the art industrial technologies to telescope control and monitoring systems.
The Cherenkov Telescope Array (CTA) is an international initiative to build the next generation ground-based gamma-ray instrument. CTA will allow studying the Universe in the very-high-energy gamma-ray domain with energies ranging from a few tens of GeV to more than a hundred TeV. It will extend the currently accessible energy band, while increasing the sensitivity by a factor of 10 with respect to existing Cherenkov facilities. Furthermore, CTA will enhance other important aspects like angular and energy resolution. CTA will comprise two arrays, one in the Northern hemisphere and one in the Southern hemisphere, of in total more than one hundred of telescopes of three different sizes. The CTA performance requirements and the increased complexity in operation, control and monitoring of such a large distributed multi-telescope array leads to new challenges in designing and developing the CTA control software system. Indeed, the control software system must be flexible enough to allow for the simultaneous operation of multiple sub-arrays of different types of telescopes, to be ready to react in short timescales to changing weather conditions or to automatic alarms for transient phenomena, to be able to operate the observatory with a minimum personal effort on site, to cope with the malfunctioning of single telescopes or sub-arrays of telescopes, and to readout and control a large and heterogeneous set of devices. This report describes the preliminary architectural design concept for the CTA control software system that will be responsible to manage all the functionality of the CTA array, thereby enabling CTA to reach its scientific goals.
ASTRI (Astrofisica con Specchi a Tecnologia Replicante Italiana) is a Flagship Project financed by the Italian Ministry of Education, University and Research, and led by INAF, the Italian National Institute of Astrophysics. The main goals of the ASTRI project are the realization of an end-to-end prototype of a Small Size Telescope (SST) for the Cherenkov Telescope Array (CTA) in a dual- mirror configuration (SST-2M) and, subsequently, of a mini-array comprising seven SST-2M telescopes. The mini-array will be placed at the final CTA Southern Site, which will be part of the CTA seed array, around which the whole CTA observatory will be developed. The Mini-Array Software System (MASS) will provide a comprehensive set of tools to prepare an observing proposal, to perform the observations specified therein (monitoring and controlling all the hardware components of each telescope), to analyze the acquired data online and to store/retrieve all the data products to/from the archive. Here we present the main features of the MASS and its first version, to be tested on the ASTRI SST-2M prototype that will be installed at the INAF observing station located at Serra La Nave on Mount Etna in Sicily.
The ALMA radio-telescope, currently under construction in northern Chile, is a very advanced instrument that
presents numerous challenges. From a software perspective, one critical issue is the design of graphical user
interfaces for operations monitoring and control that scale to the complexity of the system and to the massive
amounts of data users are faced with. Early experience operating the telescope with only a few antennas has
shown that conventional user interface technologies are not adequate in this context. They consume too much
screen real-estate, require many unnecessary interactions to access relevant information, and fail to provide
operators and astronomers with a clear mental map of the instrument. They increase extraneous cognitive load,
impeding tasks that call for quick diagnosis and action.
To address this challenge, the ALMA software division adopted a user-centered design approach. For the
last two years, astronomers, operators, software engineers and human-computer interaction researchers have
been involved in participatory design workshops, with the aim of designing better user interfaces based on
state-of-the-art visualization techniques. This paper describes the process that led to the development of those
interface components and to a proposal for the science and operations console setup: brainstorming sessions,
rapid prototyping, joint implementation work involving software engineers and human-computer interaction
researchers, feedback collection from a broader range of users, further iterations and testing.
At the end of 2012, ALMA software development will be completed. While new releases are still being prepared
following an incremental development process, the ALMA software has been in daily use since 2008. Last year it was
successfully used for the first science observations proposed by and released to the ALMA scientific community. This
included the whole project life cycle from proposal preparation to data delivery, taking advantage of the software being
designed as an end-to-end system. This presentation will report on software management aspects that became relevant in
the last couple of years. These include a new feature driven development cycle, an improved software verification
process, and a more realistic test environment at the observatory. It will also present a forward look at the planned
transition to full operations, given that upgrades, optimizations and maintenance will continue for a long time.
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 number of tools exist to aid in the preparation of proposals and observations for large ground and space-based observatories (VLT, Gemini, HST being examples). These tools have transformed the way in which astronomers use large telescopes. The ALMA telescope has a strong need for such a tool, but its scientific and technical requirements, and the nature of the telescope, provide some novel challenges. In addition to the common Phase I (Proposal) and Phase II (Observing) preparation the tool must support the needs of the novice alongside the needs of those who are expert in millimetre/sub-millimetre aperture synthesis astronomy. We must also provide support for the reviewing process, and must interface with and use the technical architecture underpinning the design of the ALMA Software System. In this paper we describe our approach to meeting these challenges.
The software for the Atacama Large Millimeter Array (ALMA) is being developed by many institutes on two continents. The software itself
will function in a distributed environment, from the 0.5-14 kmbaselines that separate antennas to the larger distances that
separate the array site at the Llano de Chajnantor in Chile from the operations and user support facilities in Chile, North America
and Europe. Distributed development demands 1) interfaces that allow separated groups to work with minimal dependence on their counterparts
at other locations; and 2) a common architecture to minimize duplication and ensure that developers can always perform similar
tasks in a similar way. The Container/Component model provides a blueprint for the separation of functional from technical concerns:
application developers concentrate on implementing functionality in Components, which depend on Containers to provide them with
services such as access to remote resources, transparent serialization of entity objects to XML, logging, error handling and security. Early system integrations have verified that this architecture is sound and that developers can successfully exploit its features. The Containers and their services are provided by a system-orienteddevelopment team as part of the ALMA Common Software (ACS), middleware that is based on CORBA.
The Atacama Large Millimeter Array (ALMA) is a joint project involving 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. It will be located at an altitude of about 5000m in the Chilean Atacama desert.
The primary challenge to the development of the software architecture is the fact that both its development and runtime environments will be distributed. Groups at different institutes will develop the key elements such as Proposal Preparation tools, Instrument operation, On-line calibration and reduction, and Archiving. The Proposal Preparation software will be used primarily at scientists' home institutions (or on their laptops), while Instrument Operations will execute on a set of networked computers at the ALMA Operations Support Facility. The ALMA Science Archive, itself to be replicated at several sites, will serve astronomers worldwide.
Building upon the existing ALMA Common Software (ACS), the system architects will prepare a robust framework that will use XML-encoded entity objects to provide an effective solution to the persistence needs of this system, while remaining largely independent of any underlying DBMS technology. Independence of distributed subsystems will be facilitated by an XML- and CORBA-based pass-by-value mechanism for exchange of objects. Proof of concept (as well as a guide to subsystem developers) will come from a prototype whose details will be presented.