This PDF file contains the front matter associated with SPIE Proceedings Volume 9913, including the Title Page, Copyright information, Table of Contents, Introduction (if any), and Conference Committee listing.

The SKA radio telescope project is building two telescopes, SKA-Low in Australia and SKA-Mid in South Africa respectively. The Telescope Manager is responsible for the observations lifecycle and for monitoring and control of each instrument, and is being developed by an international consortium. The project is currently in the design phase, with the Preliminary Design Review having been successfully completed, along with re-baselining to match project scope to available budget. This report presents the status of the Telescope Manager work, key architectural challenges and our approach to addressing them.

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.

The Atacama Large Millimeter/Submillimeter Array (ALMA) is a set of 66 millimeter wave antenna in the Andes in Northern Chile. All antennas are connected and operate as an interferometer making ALMA the most powerful millimeter telescope in the world. In 2013 ALMA formally marked the end of construction and the beginning of operations. This paper will focus on the impact, on the ALMA control software, of this transition from construction to operations.

Pointing and tracking performance is one of the key metrics that characterize a telescope's overall efficiency. The pointing performance of the Keck telescopes, which use rotary friction encoders to provide position feedback to the control system, has been surpassed by newer large telescopes with more precise encoder systems. While poor tracking can be compensated with guiding, poor blind pointing performance can lead to loss of observing time. In this paper we present a history of the efforts to reduce the impact of poor pointing, as well as the improvements achieved after the installation of new tape encoders. We will discuss the calibration and testing methods and the tools for monitoring and maintaining the desired pointing performance. A comparative analysis of the pointing performance before and after the telescope control system upgrade will also be presented.

The Tian Ma Telescope (TM) is the largest fully steerable radio telescope in Asia. It has a primary reflector of 65-m in diameter with a shaped Cassegrain configuration. The primary reflector of the TM is an active surface with 1104 actuators for the 1008 surface panels. The panels of the telescope are divided into 18 rings, and 24 fan sections. Each section includes three sub-sections. The active surface system adopts TCP/IP Ethernet network and RS-485 bus as a dominating mode of communication. The control software works on the Windows system, and adopts the object-oriented technology. The photogrammetry and phase-coherent holography has been used to set the surface to about 0.3mm at the rigging angle. The FEM model is testing now. The Out-of-Focus holography and other techniques will be used to modify the dynamic surface deformation.

SOFIA is an airborne observatory, operating a gyroscopically stabilized telescope with an effective aperture of 2.5 m on-board a modified Boeing 747SP. Its primary objective is to conduct observations at mid- to far-infrared wavelengths. When SOFIA opens its door to the night sky, the initial telescope pointing is estimated from the aircraft's position and heading as well as the telescope's attitude relative to the aircraft. This initial pointing estimate needs to be corrected using stars that are manually identified in tracking camera images; telescope pointing also needs to be verified and refined at the beginning of each flight leg. We report about the implementation of the astrometry.net package on the telescope operator workstations on-board SOFIA. This package provides a very robust, reliable and fast algorithm for blind astrometric image calibration. Using images from SOFIA's Wide Field Imager, we are able to display an almost instant, continuous feedback of calculated right ascension, declination and field rotation in the GUI for the telescope operator. The computer-aided recognition of star patterns will support telescope pointing calibrations in the future, further increasing the efficiency of the observatory. We also discuss other current and future use cases of the astrometry.net package in the SOFIA project and at the German SOFIA Institute (DSI).

The Greenland Telescope (GLT) is a 12m diameter antenna that is being developed from the ALMA North America prototype antenna, for VLBI observations and single-dish science approaching THz, at the Summit station in Greenland. The GLT is a collaboration between the Smithsonian Astrophysical Observatory and the Academia Sinica Institute of Astronomy and Astrophysics. We describe the control and monitoring software that is being developed for GLT. The present version of the software is ready for the initial tests of the antenna at Thule, including optical and radio pointing calibration, holography, and VLBI observations at 230 GHz.

Construction of the Large Synoptic Survey Telescope system involves several different organizations, a situation that poses many challenges at the time of the software integration of the components. To ensure commonality for the purposes of usability, maintainability, and robustness, the LSST software teams have agreed to the following for system software components: a summary state machine, a manner of managing settings, a flexible solution to specify controller/controllee relationships reliably as needed, and a paradigm for responding to and communicating alarms. This paper describes these agreed solutions and the factors that motivated these.

This paper introduces and discusses the design of an Automated Qualification Framework (AQF) that was developed to automate as much as possible of the formal Qualification Testing of the Control And Monitoring (CAM) subsystem of the 64 dish MeerKAT radio telescope currently under construction in the Karoo region of South Africa. The AQF allows each Integrated CAM Test to reference the MeerKAT CAM requirement and associated verification requirement it covers and automatically produces the Qualification Test Procedure and Qualification Test Report from the test steps and evaluation steps annotated in the Integrated CAM Tests. The MeerKAT System Engineers are extremely happy with the AQF results, but mostly by the approach and process it enforces.

The software maintenance typically requires 40-80% of the overall project costs, and this considerable variability mostly depends on the software internal quality: the more the software is designed and implemented to constantly welcome new changes, the lower will be the maintenance costs. The internal quality is typically enforced through testing, which in turn also affects the development and maintenance costs. This is the reason why testing methodologies have become a major concern for any company that builds - or is involved in building - software. Although there is no testing approach that suits all contexts, we infer some general guidelines learned during the Development of the Italian Single-dish COntrol System (DISCOS), which is a project aimed at producing the control software for the three INAF radio telescopes (the Medicina and Noto dishes, and the newly-built SRT). These guidelines concern both the development and the maintenance phases, and their ultimate goal is to maximize the DISCOS software quality through a Behavior-Driven Development (BDD) workflow beside a continuous delivery pipeline. We consider different topics and patterns; they involve the proper apportion of the tests (from end-to-end to low-level tests), the choice between hardware simulators and mockers, why and how to apply TDD and the dependency injection to increase the test coverage, the emerging technologies available for test isolation, bug fixing, how to protect the system from the external resources changes (firmware updating, hardware substitution, etc.) and, eventually, how to accomplish BDD starting from functional tests and going through integration and unit tests. We discuss pros and cons of each solution and point out the motivations of our choices either as a general rule or narrowed in the context of the DISCOS project.

ALMA software development cycle includes well defined testing stages that involves developers, testers and scientists. We adapted Behavior Driven Development (BDD) to testing activities applied to Telescope Calibration (TELCAL) software. BDD is an agile technique that encourages communication between roles by defining test cases using natural language to specify features and scenarios, what allows participants to share a common language and provides a high level set of automated tests. This work describes how we implemented and maintain BDD testing for TELCAL, the infrastructure needed to support it and proposals to expand this technique to other subsystems.

The Atacama Large Millimeter /submillimeter Array (ALMA) has entered into operation phase since 2013. This transition changed the priorities within the observatory, in which, most of the available time will be dedicated to science observations at the expense of technical time. Therefore, it was planned to design and implement a new simulation environment, which must be comparable - or at least- be representative of the production environment. Concepts of model in the loop and hardware in the loop were explored. In this paper we review experiences gained and lessons learnt during the design and implementation of the new simulation environment.

The paper describes the introduction of a new automatized build and test infrastructure, based on the open-source software Jenkins¹, 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.

Astronomical data sets are growing ever larger, and the area of high contrast imaging of exoplanets is no exception. With the advent of fast, low-noise detectors operating at 10 to 1000 Hz, huge numbers of images can be taken during a single hours-long observation. High frame rates offer several advantages, such as improved registration, frame selection, and improved speckle calibration. However, advanced image processing algorithms are computationally challenging to apply. Here we describe a parallelized, cloud-based data reduction system developed for the Magellan Adaptive Optics VisAO camera, which is capable of rapidly exploring tens of thousands of parameter sets affecting the Karhunen-Loève image processing (KLIP) algorithm to produce high-quality direct images of exoplanets. We demonstrate these capabilities with a visible wavelength high contrast data set of a hydrogen-accreting brown dwarf companion.

The Large Synoptic Survey Telescope (LSST) will be an 8.4m optical survey telescope sited in Chile and capable of imaging the entire sky twice a week. The data rate of approximately 15TB per night and the requirements to both issue alerts on transient sources within 60 seconds of observing and create annual data releases means that automated data management systems and data processing pipelines are a key deliverable of the LSST construction project. The LSST data management software has been in development since 2004 and is based on a C++ core with a Python control layer. The software consists of nearly a quarter of a million lines of code covering the system from fundamental WCS and table libraries to pipeline environments and distributed process execution. The Astropy project began in 2011 as an attempt to bring together disparate open source Python projects and build a core standard infrastructure that can be used and built upon by the astronomy community. This project has been phenomenally successful in the years since it has begun and has grown to be the de facto standard for Python software in astronomy. Astropy brings with it considerable expectations from the community on how astronomy Python software should be developed and it is clear that by the time LSST is fully operational in the 2020s many of the prospective users of the LSST software stack will expect it to be fully interoperable with Astropy. In this paper we describe the overlap between the LSST science pipeline software and Astropy software and investigate areas where the LSST software provides new functionality. We also discuss the possibilities of re-engineering the LSST science pipeline software to build upon Astropy, including the option of contributing affliated packages.

The VIALACTEA project has a work package dedicated to “Tools and Infrastructure" and, inside it, a task for the “Database and Virtual Observatory Infrastructure". This task aims at providing an infrastructure to store all the resources needed by the, more purposely, scientific work packages of the project itself. This infrastructure includes a combination of: storage facilities, relational databases and web services on top of them, and has taken, as a whole, the name of VIALACTEA Knowledge Base (VLKB). This contribution illustrates the current status of this VLKB. It details the set of data resources put together; describes the database that allows data discovery through VO inspired metadata maintenance; illustrates the discovery, cutout and access services built on top of the former two for the users to exploit the data content.

The Keck Observatory Archive (KOA) (https://koa.ipac.caltech.edu) curates all observations acquired at the W. M. Keck Observatory (WMKO) since it began operations in 1994, including data from eight active instruments and two decommissioned instruments. The archive is a collaboration between WMKO and the NASA Exoplanet Science Institute (NExScI). Since its inception in 2004, the science information system used at KOA has adopted an architectural approach that emphasizes software re-use and adaptability. This paper describes how KOA is currently leveraging and extending open source software components to develop new services and to support delivery of a complete set of instrument metadata, which will enable more sophisticated and extensive queries than currently possible.

In August 2015, KOA deployed a program interface to discover public data from all instruments equipped with an imaging mode. The interface complies with version 2 of the Simple Imaging Access Protocol (SIAP), under development by the International Virtual Observatory Alliance (IVOA), which defines a standard mechanism for discovering images through spatial queries. The heart of the KOA service is an R-tree-based, database-indexing mechanism prototyped by the Virtual Astronomical Observatory (VAO) and further developed by the Montage Image Mosaic project, designed to provide fast access to large imaging data sets as a first step in creating wide-area image mosaics (such as mosaics of subsets of the 4.7 million images of the SDSS DR9 release). The KOA service uses the results of the spatial R-tree search to create an SQLite data database for further relational filtering. The service uses a JSON configuration file to describe the association between instrument parameters and the service query parameters, and to make it applicable beyond the Keck instruments.

The images generated at the Keck telescope usually do not encode the image footprints as WCS fields in the FITS file headers. Because SIAP searches are spatial, much of the effort in developing the program interface involved processing the instrument and telescope parameters to understand how accurately we can derive the WCS information for each instrument. This knowledge is now being fed back into the KOA databases as part of a program to include complete metadata information for all imaging observations.

The R-tree program was itself extended to support temporal (in addition to spatial) indexing, in response to requests from the planetary science community for a search engine to discover observations of Solar System objects. With this 3D-indexing scheme, the service performs very fast time and spatial matches between the target ephemerides, obtained from the JPL SPICE service. Our experiments indicate these matches can be more than 100 times faster than when separating temporal and spatial searches. Images of the tracks of the moving targets, overlaid with the image footprints, are computed with a new command-line visualization tool, mViewer, released with the Montage distribution. The service is currently in test and will be released in late summer 2016.

The Square Kilometre Array Telescope Manager (SKA TM) will be responsible for assisting the SKA Operations and Observation Management, carrying out System diagnosis and collecting Monitoring and Control data from the SKA subsystems and components. To provide adequate compute resources, scalability, operation continuity and high availability, as well as strict Quality of Service, the TM cyber-infrastructure (embodied in the Local Infrastructure - LINFRA) consists of COTS hardware and infrastructural software (for example: server monitoring software, host operating system, virtualization software, device firmware), providing a specially tailored Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) solution. The TM infrastructure provides services in the form of computational power, software defined networking, power, storage abstractions, and high level, state of the art IaaS and PaaS management interfaces. This cyber platform will be tailored to each of the two SKA Phase 1 telescopes (SKA_MID in South Africa and SKA_LOW in Australia) instances, each presenting different computational and storage infrastructures and conditioned by location. This cyber platform will provide a compute model enabling TM to manage the deployment and execution of its multiple components (observation scheduler, proposal submission tools, MandC components, Forensic tools and several Databases, etc). In this sense, the TM LINFRA is primarily focused towards the provision of isolated instances, mostly resorting to virtualization technologies, while defaulting to bare hardware if specifically required due to performance, security, availability, or other requirement.

The NOAO Data Lab aims to provide infrastructure to maximize community use of the high-value survey datasets now being collected with NOAO telescopes and instruments. As a science exploration framework, the Data Lab allow users to access and search databases containing large (i.e. terabyte-scale) catalogs, visualize, analyze, and store the results of these searches, combine search results with data from other archives or facilities, and share these results with collaborators using a shared workspace and/or data publication service. In the process of implementing the needed tools and services, specific science cases are used to guide development of the system framework and tools. The result is a Year-1 capability demonstration that (fully or partially) implements each of the major architecture components in the context of a real-world science use-case. In this paper, we discuss how this model of science-driven development helped us to build a fully functional system capable of executing the chosen science case, and how we plan to scale this system to support general use in the next phase of the project.

We have developed a specialized software package, called ast3suite, to achieve the remote control and automatic sky survey for AST3 (Antarctic Survey Telescope) from scratch. It includes several daemon servers and many basic commands. Each program does only one single task, and they work together to make AST3 a robotic telescope. A survey script calls basic commands to carry out automatic sky survey. Ast3suite was carefully tested in Mohe, China in 2013 and has been used at Dome, Antarctica in 2015 and 2016 with the real hardware for practical sky survey. Both test results and practical using showed that ast3suite had worked very well without any manual auxiliary as we expected.

TMT Common Software (CSW). CSW consists of software services and library code that is used by developers to create the subsystems and components that participate in the software system. CSW also defines the types of components that can be constructed and their functional roles in the software system. TMT CSW has recently passed its preliminary design review. The unique features of CSW include its use of multiple, open-source products as the basis for services, and an approach that works to reduce the amount of CSW-provided infrastructure code. Considerable prototyping was completed during this phase to mitigate risk with results that demonstrate the validity of this design approach and the selected service implementation products. This paper describes the latest design of TMT CSW, key features, and results from the prototyping effort.

The Southern African Large Telescope (SALT) software control system1 is realised as a distributed control system, implemented predominantly in National Instruments' LabVIEW. The telescope control subsystems communicate using cyclic, state-based messages. Currently, transmitting a message is accomplished by performing an HTTP PUT request to a WebDAV directory on a centralised Apache web server, while receiving is based on polling the web server for new messages. While the method works, it presents a number of drawbacks; a scalable distributed communication solution with minimal overhead is a better fit for control systems. This paper describes our exploration of the Data Distribution Service (DDS). DDS is a formal standard specification, defined by the Object Management Group (OMG), that presents a data-centric publish-subscribe model for distributed application communication and integration. It provides an infrastructure for platform- independent many-to-many communication. A number of vendors provide implementations of the DDS standard; RTI, in particular, provides a DDS toolkit for LabVIEW. This toolkit has been evaluated against the needs of SALT, and a few deficiencies have been identified. We have developed our own implementation that interfaces LabVIEW to DDS in order to address our specific needs. Our LabVIEW DDS interface implementation is built against the RTI DDS Core component, provided by RTI under their Open Community Source licence. Our needs dictate that the interface implementation be platform independent. Since we have access to the RTI DDS Core source code, we are able to build the RTI DDS libraries for any of the platforms on which we require support. The communications functionality is based on UDP multicasting. Multicasting is an efficient communications mechanism with low overheads which avoids duplicated point-to-point transmission of data on a network where there are multiple recipients of the data. In the paper we present a performance evaluation of DDS against the current HTTP-based implementation as well as the historical DataSocket implementation. We conclude with a summary and describe future work.

The Dark Energy Spectroscopic Instrument (DESI) , a new instrument currently under construction for the Mayall 4m telescope at Kitt Peak National Observatory, will consist of a wide-field optical corrector with a 3.2 degree diameter field of view, a focal plane with 5,000 robotically controlled fiber positioners and 10 fiber fed broadband spectrographs. This article describes the design of the DESI instrument control system (ICS). The ICS coordinates fiber positioner operations, interfaces to the Mayall telescope control system, monitors operating conditions, reads out the 30 spectrograph CCDs and provides observer support and data quality monitoring.

Differential evolution (DE) is a powerful and computationally inexpensive optimization strategy that can be used to search an entire parameter space or to converge quickly on a solution. The Kilopixel Array Pathfinder Project (KAPPa) is a heterodyne receiver system delivering 5 GHz of instantaneous bandwidth in the tuning range of 645-695 GHz. The fully automated KAPPa receiver test system finds optimal receiver tuning using performance feedback and DE. We present an adaptation of DE for use in rapid receiver characterization. The KAPPa DE algorithm is written in Python 2.7 and is fully integrated with the KAPPa instrument control, data processing, and visualization code. KAPPa develops the technologies needed to realize heterodyne focal plane arrays containing ~1000 pixels. Finding optimal receiver tuning by investigating large parameter spaces is one of many challenges facing the characterization phase of KAPPa. This is a difficult task via by-hand techniques. Characterizing or tuning in an automated fashion without need for human intervention is desirable for future large scale arrays. While many optimization strategies exist, DE is ideal for time and performance constraints because it can be set to converge to a solution rapidly with minimal computational overhead. We discuss how DE is utilized in the KAPPa system and discuss its performance and look toward the future of ~1000 pixel array receivers and consider how the KAPPa DE system might be applied.

Until recently, software for instruments on the smaller telescopes at the South African Astronomical Observatory (SAAO) has not been designed for remote accessibility and frequently has not been developed using modern software best-practice. We describe a software architecture we have implemented for use with new and upgraded instruments at the SAAO. The architecture was designed to allow for multiple components and to be fast, reliable, remotely- operable, support different user interfaces, employ as much non-proprietary software as possible, and to take future-proofing into consideration. Individual component drivers exist as standalone processes, communicating over a network. A controller layer coordinates the various components, and allows a variety of user interfaces to be used. The Sutherland High-speed Optical Cameras (SHOC) instruments incorporate an Andor electron-multiplying CCD camera, a GPS unit for accurate timing and a pair of filter wheels. We have applied the new architecture to the SHOC instruments, with the camera driver developed using Andor's software development kit. We have used this to develop an innovative web-based user-interface to the instrument.

It is a top level science requirement that data from the Daniel K Inouye Solar Telescope (DKIST) is archived and made available to the world wide astronomical community. Data from DKIST must contain sufficient meta-data to allow proper post processing. This paper describes how the Telescope Control System (TCS), Wavefront Correction Control System (WCCS) and individual instrument control systems work together with the camera systems to provide the world coordinate information (WCI) meta-data for 2-d imaging detectors.

The InfraRed Imaging Spectrograph (IRIS) will be a first-light client instrument for the Narrow Field Infrared Adaptive Optics System (NFIRAOS) on the Thirty Meter Telescope. IRIS includes three configurable tip/tilt (TT) or tip/tilt/focus (TTF) On-Instrument Wavefront Sensors (OIWFS). These sensors are positioned over natural guide star (NGS) asterisms using movable polar-coordinate pick-ofi arms (POA) that patrol an approximately 2-arcminute circular field-of-view (FOV). The POAs are capable of colliding with one another, so an algorithm for coordinated motion that avoids contact is required. We have adopted an approach in which arm motion is evaluated using the gradient descent of a scalar potential field that includes an attractive component towards the goal configuration (locations of target stars), and repulsive components to avoid obstacles (proximity to adjacent arms). The resulting vector field is further modified by adding a component transverse to the repulsive gradient to avoid problematic local minima in the potential. We present path planning simulations using this computationally inexpensive technique, which exhibit smooth and efficient trajectories.

The Australian Astronomical Observatory's TAIPAN instrument deploys 150 Starbug robots to position optical fibres to accuracies of 0.3 arcsec, on a 32 cm glass field plate on the focal plane of the 1.2 m UK-Schmidt telescope. This paper describes the software system developed to control and monitor the Starbugs, with particular emphasis on the automated path-finding algorithms, and the metrology software which keeps track of the position and motion of individual Starbugs as they independently move in a crowded field. The software employs a tiered approach to find a collision-free path for every Starbug, from its current position to its target location. This consists of three path-finding stages of increasing complexity and computational cost. For each Starbug a path is attempted using a simple method. If unsuccessful, subsequently more complex (and expensive) methods are tried until a valid path is found or the target is flagged as unreachable.

Many fiber-fed spectroscopic survey projects, such as DESI, PFS and MOONS, will use thousands of fiber positioners packed at a focal plane. To maximize observation time, the positioners need to move simultaneously and reach their targets swiftly. We have previously presented a motion planning method based on a decentralized navigation function for the collision-free coordination of the fiber positioners in DESI. In MOONS, the end effector of each positioner handling the fiber can reach the centre of its neighbours. There is therefore a risk of collision with up to 18 surrounding positioners in the chosen dense hexagonal configuration. Moreover, the length of the second arm of the positioner is almost twice the length of the first one. As a result, the geometry of the potential collision zone between two positioners is not limited to the extremity of their end-effector, but surrounds the second arm. In this paper, we modify the navigation function to take into account the larger collision zone resulting from the extended geometrical shape of the positioners. The proposed navigation function takes into account the configuration of the positioners as well as the constraints on the actuators, such as their maximal velocity and their mechanical clearance. Considering the fact that all the positioners' bases are fixed to the focal plane, collisions can occur locally and the risk of collision is limited to the 18 surrounding positioners. The decentralizing motion planning and trajectory generation takes advantage of this limited number of positioners and the locality of collisions, hence significantly reduces the complexity of the algorithm to a linear order. The linear complexity ensures short computation time. In addition, the time needed to move all the positioners to their targets is independent of the number of positioners. These two key advantages of the chosen decentralization approach turn this method to a promising solution for the collision-free motion-planning problem in the next- generation spectroscopic survey projects. A motion planning simulator, exploited as a software prototype, has been developed in Python. The pre-computed collision-free trajectories of the actuators of all the positioners are fed directly from the simulator to the electronics controlling the motors. A successful demonstration of the effectiveness of these trajectories on the real positioners as well as their simulated counterparts are put side by side in the following online video sequence (https://goo.gl/YuwwsE).

Ultra-high-resolution wall displays feature a very high pixel density over a large physical surface, which makes them well-suited to the collaborative, exploratory visualization of large datasets. We introduce FITS-OW, an application designed for such wall displays, that enables astronomers to navigate in large collections of FITS images, query astronomical databases, and display detailed, complementary data and documents about multiple sources simultaneously. We describe how astronomers interact with their data using both the wall’s touchsensitive surface and handheld devices. We also report on the technical challenges we addressed in terms of distributed graphics rendering and data sharing over the computer clusters that drive wall displays.

The Cherenkov Telescope Array (CTA) is a planned gamma-ray observatory. CTA will incorporate about 100 imaging atmospheric Cherenkov telescopes (IACTs) at a Southern site, and about 20 in the North. Previous IACT experiments have used up to five telescopes. Subsequently, the design of a graphical user interface (GUI) for the operator of CTA involves new challenges. We present a GUI prototype, the concept for which is being developed in collaboration with experts from the field of Human-Computer Interaction (HCI). The prototype is based on Web technology; it incorporates a Python web server, Web Sockets and graphics generated with the d3.js Javascript library.

At IPAC/Caltech, we have developed the Firefly web archive and visualization system. Used in production for the last eight years in many missions, Firefly gives the scientist significant capabilities to study data. Firefly provided the first completely web based FITS viewer as well as a growing set of tabular and plotting visualizers. Further, it will be used for the science user interface of the LSST telescope which goes online in 2021. Firefly must meet the needs of archive access and visualization for the 2021 LSST telescope and must serve astronomers beyond the year 2030. Recently, our team has faced the fact that the technology behind Firefly software was becoming obsolete. We were searching for ways to utilize the current breakthroughs in maintaining stability, testability, speed, and reliability of large web applications, which Firefly exemplifies. In the last year, we have ported the Firefly to cutting edge web technologies. Embarking on this massive overhaul is no small feat to say the least. Choosing the technologies that will maintain a forward trajectory in a future development project is always hard and often overwhelming. When a team must port 150,000 lines of code for a production-level product there is little room to make poor choices. This paper will give an overview of the most modern web technologies and lessons learned in our conversion from GWT based system to React/Redux based system.

The Square Kilometre Array (SKA) will be the world's most advanced radio telescope, designed to explore some of the biggest questions in astronomy today, such as the epoch of re-ionization, the nature of gravity and the origins of cosmic magnetism. SKA1, the first phase of SKA construction, is currently being designed by a large team of experts world-wide. SKA1 comprises two telescopes: a 200-element dish interferometer in South Africa and a 130000-element dipole antenna aperture array in Australia. To enable the ground-breaking science of the SKA an advanced Observation Management system is required to support both the needs of the astronomical community users and the SKA Observatory staff. This system will ensure that the SKA realises its scientiffc aims and achieves optimal scientific throughput. This paper provides an overview of the design of the system that will accept proposals from SKA users, and result in the execution of the scripts that will obtain science data, taking in the stages of detailed preparation, planning and scheduling of the observations and onwards tracking. It describes the unique challenges of the differing requirements of two telescopes, one of which is very much a software telescope, including the need to schedule the data processing as well as the acquisition, and to react to both internally and externally discovered transient events. The scheduling of multiple parallel sub-array use is covered, along with the need to handle commensal observing - using the same data stream to satisfy the science goals of more than one project simultaneously. An international team from academia and industry, drawing on expertise and experience from previous telescope projects, the virtual observatory and comparable problems in industry, has been assembled to design the solution to this challenging but exciting problem.

The Sardinia Radio Telescope (SRT) is a 64-m fully-steerable radio telescope. It is provided with an active surface to correct for gravitational deformations, allowing observations from 300 MHz to 100 GHz. At present, three receivers are available: a coaxial LP-band receiver (305-410 MHz and 1.5-1.8 GHz), a C-band receiver (5.7-7.7 GHz) and a 7-feed K-band receiver (18-26.5 GHz). Several back-ends are also available in order to perform the different data acquisition and analysis procedures requested by scientific projects. The design and development of the SRT control software started in 2004, and now belongs to a wider project called DISCOS (Development of the Italian Single-dish COntrol System), which provides a common infrastructure to the three Italian radio telescopes (Medicina, Noto and SRT dishes). DISCOS is based on the Alma Common Software (ACS) framework, and currently consists of more than 500k lines of code. It is organized in a common core and three specific product lines, one for each telescope. Recent developments, carried out after the conclusion of the technical commissioning of the instrument (October 2013), consisted in the addition of several new features in many parts of the observing pipeline, spanning from the motion control to the digital back-ends for data acquisition and data formatting; we brie y describe such improvements. More importantly, in the last two years we have supported the astronomical validation of the SRT radio telescope, leading to the opening of the first public call for proposals in late 2015. During this period, while assisting both the engineering and the scientific staff, we massively employed the control software and were able to test all of its features: in this process we received our first feedback from the users and we could verify how the system performed in a real-life scenario, drawing the first conclusions about the overall system stability and performance. We examine how the system behaves in terms of network load and system load, how it reacts to failures and errors, and what components and services seem to be the most critical parts of our architecture, showing how the ACS framework impacts on these aspects. Moreover, the exposure to public utilization has highlighted the major flaws in our development and software management process, which had to be tuned and improved in order to achieve faster release cycles in response to user feedback, and safer deploy operations. In this regard we show how the introduction of testing practices, along with continuous integration, helped us to meet higher quality standards. Having identified the most critical aspects of our software, we conclude showing our intentions for the future development of DISCOS, both in terms of software features and software infrastructures.

The Australian SKA Pathfinder (ASKAP) is a novel centimetre radio synthesis telescope currently in the commissioning phase and located in the midwest region of Western Australia. It comprises of 36 x 12 m diameter reflector antennas each equipped with state-of-the-art and award winning Phased Array Feeds (PAF) technology. The PAFs provide a wide, 30 square degree field-of-view by forming up to 36 separate dual-polarisation beams at once. This results in a high data rate: 70 TB of correlated visibilities in an 8-hour observation, requiring custom-written, high-performance software running in dedicated High Performance Computing (HPC) facilities. The first six antennas equipped with first-generation PAF technology (Mark I), named the Boolardy Engineering Test Array (BETA) have been in use since 2014 as a platform to test PAF calibration and imaging techniques, and along the way it has been producing some great science results. Commissioning of the ASKAP Array Release 1, that is the first six antennas with second-generation PAFs (Mark II) is currently under way. An integral part of the instrument is the Central Processor platform hosted at the Pawsey Supercomputing Centre in Perth, which executes custom-written software pipelines, designed specifically to meet the ASKAP imaging requirements of wide field of view and high dynamic range. There are three key hardware components of the Central Processor: The ingest nodes (16 x node cluster), the fast temporary storage (1 PB Lustre file system) and the processing supercomputer (200 TFlop system). This High-Performance Computing (HPC) platform is managed and supported by the Pawsey support team. Due to the limited amount of data generated by BETA and the first ASKAP Array Release, the Central Processor platform has been running in a more “traditional” or user-interactive mode. But this is about to change: integration and verification of the online ingest pipeline starts in early 2016, which is required to support the full 300 MHz bandwidth for Array Release 1; followed by the deployment of the real-time data processing components. In addition to the Central Processor, the first production release of the CSIRO ASKAP Science Data Archive (CASDA) has also been deployed in one of the Pawsey Supercomputing Centre facilities and it is integrated to the end-to-end ASKAP data flow system. This paper describes the current status of the “end-to-end” data flow software system from preparing observations to data acquisition, processing and archiving; and the challenges of integrating an HPC facility as a key part of the instrument. It also shares some lessons learned since the start of integration activities and the challenges ahead in preparation for the start of the Early Science program.

Astronomical instruments often need simulators to preview their data products and test their data reduction pipelines. Instrument simulators have tended to be purpose-built with a single instrument in mind, and at- tempting to reuse one of these simulators for a different purpose is often a slow and difficult task. MAISIE is a simulator framework designed for reuse on different instruments. An object-oriented design encourages reuse of functionality and structure, while offering the flexibility to create new classes with new functionality. MAISIE is a set of Python classes, interfaces and tools to help build instrument simulators. MAISIE can just as easily build simulators for single and multi-channel instruments, imagers and spectrometers, ground and space based instruments. To remain easy to use and to facilitate the sharing of simulators across teams, MAISIE is written in Python, a freely available and open-source language. New functionality can be created for MAISIE by creating new classes that represent optical elements. This approach allows new and novel instruments to add functionality and take advantage of the existing MAISIE classes. MAISIE has recently been used successfully to develop the simulator for the JWST/MIRI- Medium Resolution Spectrometer.

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.

Monitoring and prediction of astronomical observing conditions are essential for planning and optimizing observations. For this purpose, ESO, in the 90s, developed the concept of an Astronomical Site Monitor (ASM), as a facility fully integrated in the operations of the VLT observatory_[1]. Identical systems were installed at Paranal and La Silla, providing comprehensive local weather information. By now, we had very good reasons for a major upgrade:

• The need of introducing new features to satisfy the requirements of observing with the Adaptive Optics Facility and to benefit other Adaptive Optics systems.

• Managing hardware and software obsolescence.

• Making the system more maintainable and expandable by integrating off-the-shelf hardware solutions.

The new ASM integrates:

• A new Differential Image Motion Monitor (DIMM) paired with a Multi Aperture Scintillation Sensor (MASS) to measure the vertical distribution of turbulence in the high atmosphere and its characteristic velocity.

• A new SLOpe Detection And Ranging (SLODAR) telescope, for measuring the altitude and intensity of turbulent layers in the low atmosphere.

• A water vapour radiometer to monitor the water vapour content of the atmosphere.

• The old weather tower, which is being refurbished with new sensors. The telescopes and the devices integrated are commercial products and we have used as much as possible the control system from the vendors. The existing external interfaces, based on the VLT standards, have been maintained for full backward compatibility. All data produced by the system are directly fed in real time into a relational database. A completely new web-based display replaces the obsolete plots based on HP-UX RTAP. We analyse here the architectural and technological choices and discuss the motivations and trade-offs.

In the framework of the international Cherenkov Telescope Array (CTA) gamma-ray observatory, the Italian National Institute for Astrophysics (INAF) is developing a dual-mirror, small-sized, end-to-end prototype (ASTRI SST-2M), inaugurated on September 2014 at Mt. Etna (Italy), and a mini-array composed of nine ASTRI telescopes, proposed to be installed at the southern CTA site. The ASTRI mini-array is a collaborative effort led by INAF and carried out by institutes from Italy, Brazil, and South-Africa. The project is also including the full data handling chain from raw data up to final scientific products. To this end, a dedicated software for the online/ on-site/off-site data reconstruction and scientific analysis is under development for both the ASTRI SST-2M prototype and mini-array. The software is designed following a modular approach in which each single component and the entire pipeline are developed in compliance with the CTA requirements. Data reduction is conceived to be run on parallel computing architectures, as multi-core CPUs and graphic accelerators (GPUs), and new hardware architectures based on low-power consumption processors (e.g. ARM). The software components are coded in C++/Python/CUDA and wrapped by efficient pipelines written in Python. The final scientific products are then achieved by means of either science tools currently being used in the CTA Consortium (e.g. ctools) or specifically developed ones. In this contribution, we present the framework and the main software components of the ASTRI SST-2M prototype and mini-array data reconstruction and scientific analysis software package, and report the status of its development.

We present a new automated photometric pipeline optimized for time-series photometry that includes a real-time data streaming service. An observer using this resource can automatically stream photometric data over the Internet. Other observers can then monitor the data stream in real time and make an informed decision whether to perform complementary observations of a transient event in progress. Our pipeline uses a modular design so that it can be easily implemented or customized as a real-time robotic telescope pipeline on any observatory. The pipeline is controlled through the user friendly SAOImage DS9 package.

The Liverpool Telescope automated spectral data reduction pipelines perform both removal of instrumental signatures and provide wavelength calibrated data products promptly after observation. Unique science drivers for each of three instruments led to novel hardware solutions which required reassessment of some of the conventional CCD reduction recipes. For example, we describe the derivation of bias and dark corrections on detectors with neither overscan or shutter. In the context of spectroscopy we compare the quality of at fielding resulting from different algorithmic combinations of dispersed and non-dispersed sky and lamp flats in the case of spectra suffering from 2D spatial distortions.

Surging data volumes make it increasingly unfeasible to transfer astronomical datasets to the local systems of individual scientists. Centralized pipelines offer some relief, but lack flexibility to fulfill the needs of all users. We have developed a system that leverages the Docker container application virtualization software. Along with a suite of commonly used astronomy applications, users can configure a container with their own custom software and analysis tools. Our StarDock system will move the users container to the data, and expose the requested dataset, allowing our users to safely and securely process their data without needlessly transferring hundreds of gigabytes.

The purpose of the Observatory Software System (OSW) is to integrate all software and hardware components of the Thirty Meter Telescope (TMT) to enable observations and data capture; thus it is a complex software system that is defined by four principal software subsystems: Common Software (CSW), Executive Software (ESW), Data Management System (DMS) and Science Operations Support System (SOSS), all of which have interdependencies with the observatory control systems and data acquisition systems. Therefore, the software development process and plan must consider dependencies to other subsystems, manage architecture, interfaces and design, manage software scope and complexity, and standardize and optimize use of resources and tools. Additionally, the TMT Observatory Software will largely be developed in India through TMT’s workshare relationship with the India TMT Coordination Centre (ITCC) and use of Indian software industry vendors, which adds complexity and challenges to the software development process, communication and coordination of activities and priorities as well as measuring performance and managing quality and risk. The software project management challenge for the TMT OSW is thus a multi-faceted technical, managerial, communications and interpersonal relations challenge. The approach TMT is using to manage this multifaceted challenge is a combination of establishing an effective geographically distributed software team (Integrated Product Team) with strong project management and technical leadership provided by the TMT Project Office (PO) and the ITCC partner to manage plans, process, performance, risk and quality, and to facilitate effective communications; establishing an effective cross-functional software management team composed of stakeholders, OSW leadership and ITCC leadership to manage dependencies and software release plans, technical complexities and change to approved interfaces, architecture, design and tool set, and to facilitate effective communications; adopting an agile-based software development process across the observatory to enable frequent software releases to help mitigate subsystem interdependencies; defining concise scope and work packages for each of the OSW subsystems to facilitate effective outsourcing of software deliverables to the ITCC partner, and to enable performance monitoring and risk management. At this stage, the architecture and high-level design of the software system has been established and reviewed. During construction each subsystem will have a final design phase with reviews, followed by implementation and testing. The results of the TMT approach to the Observatory Software development process will only be preliminary at the time of the submittal of this paper, but it is anticipated that the early results will be a favorable indication of progress.

ALMA is still a young and evolving observatory with a very active software development group that produces new and updated software components regularly. Yet we are coming to realize that - after well over a decade of development - not only our own software, but also technologies and tools we depend upon, as well as the hardware we interface with, are coming of age. Software obsolescence management is needed, but surprisingly is not something we can just borrow from other observatories, or any other comparable organization. Here we present the challenges, our approaches and some early experiences.

Euclid is an ESA mission aimed at understanding the nature of dark energy and dark matter by using simultaneously two probes (weak lensing and baryon acoustic oscillations). The mission will observe galaxies and clusters of galaxies out to z~2, in a wide extra-galactic survey covering 15000 deg², plus a deep survey covering an area of 40 deg². The payload is composed of two instruments, an imager in the visible domain (VIS) and an imager-spectrometer (NISP) covering the near-infrared. The launch is planned in Q4 of 2020. The elements of the Euclid Science Ground Segment (SGS) are the Science Operations Centre (SOC) operated by ESA and nine Science Data Centres (SDCs) in charge of data processing, provided by the Euclid Consortium (EC), formed by over 110 institutes spread in 15 countries. SOC and the EC started several years ago a tight collaboration in order to design and develop a single, cost-efficient and truly integrated SGS. The distributed nature, the size of the data set, and the needed accuracy of the results are the main challenges expected in the design and implementation of the SGS. In particular, the huge volume of data (not only Euclid data but also ground based data) to be processed in the SDCs will require distributed storage to avoid data migration across SDCs. This paper describes the management challenges that the Euclid SGS is facing while dealing with such complexity. The main aspect is related to the organisation of a geographically distributed software development team. In principle algorithms and code is developed in a large number of institutes, while data is actually processed at fewer centers (the national SDCs) where the operational computational infrastructures are maintained. The software produced for data handling, processing and analysis is built within a common development environment defined by the SGS System Team, common to SOC and ECSGS, which has already been active for several years. The code is built incrementally through different levels of maturity, going from prototypes (developed mainly by scientists) to production code (engineered and tested at the SDCs). A number of incremental challenges (infrastructure, data processing and integrated) have been included in the Euclid SGS test plan to verify the correctness and accuracy of the developed systems.

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.

We have developed and deployed a new data archive for the Gemini Observatory. Focused on simplicity and ease of use, the archive provides a number of powerful and novel features including automatic association of calibration data with the science data, and the ability to bookmark searches. A simple but powerful API allows programmatic search and download of data. The archive is hosted on Amazon Web Services, which provides us excellent internet connectivity and significant cost savings in both operations and development over more traditional deployment options. The code is written in python, utilizing a PostgreSQL database and Apache web server.

The Daniel K Inouye Solar Telescope, under construction in Maui, is designed to perform high-resolution spectropolarimetric visible and infrared measurements of the Sun, and will annually produce 3 PB of data, via 5x10⁸ images and 2x10¹¹ metadata elements requiring calibration, long-term data management, and open and free distribution. After briefly describing the DKIST and its instrument suite, we provide an overview of functions that the DKIST Data Center will provide, and focus on major challenges in its development. We conclude by discussing approach and mention some technologies that the Data Center team is using to develop a petascale computational and data storage resource to support this unique world-class DKIST facility and support its long-term scientific and operational goals.

The research on computational methods for astronomy performed by the first phase of the Chilean Virtual Observatory (ChiVO) led to the development of functional prototypes, implementing state-of-the-art computational methods and proposing new algorithms and techniques. The ChiVO software architecture is based on the use of the IVOA protocols and standards. These protocols and standards are grouped in layers, with emphasis on the application and data layers, because their basic standards define the minimum operation that a VO should conduct. As momentary verification, the current implementation works with a set of data, with 1 TB capacity, which comes from the reduction of the cycle 0 of ALMA. This research was mainly focused on spectroscopic data cubes coming from the cycle 0 ALMA's public data. As the dataset size increases when the cycle 1 ALMA's public data is also increasing every month, data processing is becoming a major bottleneck for scientific research in astronomy. When designing the ChiVO, we focused on improving both computation and I/ O costs, and this led us to configure a data center with 424 high speed cores of 2,6 GHz, 1 PB of storage (distributed in hard disk drives-HDD and solid state drive-SSD) and high speed communication Infiniband. We are developing a cloud based e-infrastructure for ChiVO services, in order to have a coherent framework for developing novel web services for on-line data processing in the ChiVO. We are currently parallelizing these new algorithms and techniques using HPC tools to speed up big data processing, and we will report our results in terms of data size, data distribution, number of cores and response time, in order to compare different processing and storage configurations.

The Astronomy scientific community has embraced Big Data processing challenges, e.g. associated with time-domain astronomy, and come up with a variety of novel and efficient data processing solutions. However, data processing is only a small part of the Big Data challenge. Efficient knowledge discovery and scientific advancement in the Big Data era requires new and equally efficient tools: modern user interfaces for searching, identifying and viewing data online without direct access to the data; tracking of data provenance; searching, plotting and analyzing metadata; interactive visual analysis, especially of (time-dependent) image data; and the ability to execute pipelines on supercomputing and cloud resources with minimal user overhead or expertise even to novice computing users. The Trident project at Indiana University offers a comprehensive web and cloud-based microservice software suite that enables the straight forward deployment of highly customized Scalable Compute Archive (SCA) systems; including extensive visualization and analysis capabilities, with minimal amount of additional coding. Trident seamlessly scales up or down in terms of data volumes and computational needs, and allows feature sets within a web user interface to be quickly adapted to meet individual project requirements. Domain experts only have to provide code or business logic about handling/visualizing their domain's data products and about executing their pipelines and application work flows. Trident's microservices architecture is made up of light-weight services connected by a REST API and/or a message bus; a web interface elements are built using NodeJS, AngularJS, and HighCharts JavaScript libraries among others while backend services are written in NodeJS, PHP/Zend, and Python. The software suite currently consists of (1) a simple work flow execution framework to integrate, deploy, and execute pipelines and applications (2) a progress service to monitor work flows and sub-work flows (3) ImageX, an interactive image visualization service (3) an authentication and authorization service (4) a data service that handles archival, staging and serving of data products, and (5) a notification service that serves statistical collation and reporting needs of various projects. Several other additional components are under development. Trident is an umbrella project, that evolved from the One Degree Imager, Portal, Pipeline, and Archive (ODI-PPA) project which we had initially refactored toward (1) a powerful analysis/visualization portal for Globular Cluster System (GCS) survey data collected by IU researchers, 2) a data search and download portal for the IU Electron Microscopy Center's data (EMC-SCA), 3) a prototype archive for the Ludwig Maximilian University's Wide Field Imager. The new Trident software has been used to deploy (1) a metadata quality control and analytics portal (RADY-SCA) for DICOM formatted medical imaging data produced by the IU Radiology Center, 2) Several prototype work flows for different domains, 3) a snapshot tool within IU's Karst Desktop environment, 4) a limited component-set to serve GIS data within the IU GIS web portal. Trident SCA systems leverage supercomputing and storage resources at Indiana University but can be configured to make use of any cloud/grid resource, from local workstations/servers to (inter)national supercomputing facilities such as XSEDE.

Collaborative research/computing environments are essential for working with the next generations of large astronomical data sets. A key component of them is a distributed storage system to enable data hosting, sharing, and publication. VOSpace¹ is a lightweight interface providing network access to arbitrary backend storage solutions and endorsed by the International Virtual Observatory Alliance (IVOA). Although similar APIs exist, such as Amazon S3, WebDav, and Dropbox, VOSpace is designed to be protocol agnostic, focusing on data control operations, and supports asynchronous and third-party data transfers, thereby minimizing unnecessary data transfers. It also allows arbitrary computations to be triggered as a result of a transfer operation: for example, a file can be automatically ingested into a database when put into an active directory or a data reduction task, such as Sextractor, can be run on it. In this paper, we shall describe the VOSpace implementations that we have developed for the NOAO Data Lab. These offer both dedicated remote storage, accessible as a local file system via FUSE, and a local VOSpace service to easily enable data synchronization.

The ASTRI SST-2M telescope is an end-to-end prototype proposed for the Small Size class of Telescopes (SST) of the future Cherenkov Telescope Array (CTA). The prototype is installed in Italy at the INAF observing station located at Serra La Nave on Mount Etna (Sicily) and it was inaugurated in September 2014. This paper presents the software and hardware architecture and development of the system dedicated to the control of the mount, health, safety and monitoring systems of the ASTRI SST-2M telescope prototype. The mount control system installed on the ASTRI SST-2M telescope prototype makes use of standard and widely deployed industrial hardware and software. State of the art of the control and automation industries was selected in order to fulfill the mount related functional and safety requirements with assembly compactness, high reliability, and reduced maintenance. The software package was implemented with the Beckhoff TwinCAT version 3 environment for the software Programmable Logical Controller (PLC), while the control electronics have been chosen in order to maximize the homogeneity and the real time performance of the system. The integration with the high level controller (Telescope Control System) has been carried out by choosing the open platform communications Unified Architecture (UA) protocol, supporting rich data model while offering compatibility with the PLC platform. In this contribution we show how the ASTRI approach for the design and implementation of the mount control system has made the ASTRI SST-2M prototype a standalone intelligent machine, able to fulfill requirements and easy to be integrated in an array configuration such as the future ASTRI mini-array proposed to be installed at the southern site of the Cherenkov Telescope Array (CTA).

This study investigates the software automation and control framework for the MMT thermal system. Thermal-related effects on observing and telescope behavior have been considered during the entire software development process. Regression analysis of telescope and observatory subsystem data is used to characterize and model these thermal-related effects. The regression models help predict expected changes in focus and overall astronomical seeing that result from temperature variations within the telescope structure, within the primary mirror glass, and between the primary mirror glass and adjacent air (i.e., mirror seeing). This discussion is followed by a description of ongoing upgrades to the heating, ventilation and air conditioning (HVAC) system and the associated software controls. The improvements of the MMT thermal system have two objectives: 1) to provide air conditioning capabilities for the MMT facilities, and 2) to modernize and enhance the primary mirror (M1) ventilation system. The HVAC upgrade necessitates changes to the automation and control of the M1 ventilation system. The revised control system must factor in the additional requirements of the HVAC system, while still optimizing performance of the M1 ventilation system and the M1’s optical behavior. An industry-standard HVAC communication and networking protocol, BACnet (Building Automation and Control network), has been adopted. Integration of the BACnet protocol into the existing software framework at the MMT is discussed. Performance of the existing automated system is evaluated and a preliminary upgraded automated control system is presented. Finally, user interfaces to the new HVAC system are discussed.

The software architecture plays an important role in distributed control system of astronomical projects because many subsystems and components must work together in a consistent and reliable way. We have utilized a customized architecture design approach based on “4+1 view model" in order to design INOCS software architecture. In this paper, after reviewing the top level INOCS architecture, we present the software architecture model of INOCS inspired by “4+1 model”, for this purpose we provide logical, process, development, physical, and scenario views of our architecture using different UML diagrams and other illustrative visual charts. Each view presents INOCS software architecture from a different perspective. We finish the paper by science data operation of INO340 and the concluding remarks.

FAST is the largest single dish radio telescope in the world. During observation, part of spherical reflector forms paraboloid to the source direction, meanwhile the feed is placed to instant focus. The control of telescope is difficult and complicated. An autonomous central control system is designed and implemented for methodically and efficiently operation. The system connects and coordinates all subsystems including control, measurement and health monitoring for reflector, feed support and receiver respectively. The main functions are managing observation tasks, commanding subsystems, storing operating data, monitoring statuses and providing the uniform time standard. In this paper, the functions, software and hardware of FAST central control system are presented. The relative infrastructures such as power, network and control room arrangement are introduced.

The primary mirror of the E-ELT is composed of 798 hexagonal segments of about 1.45 meters across. Each segment can be moved in piston and tip-tilt using three position actuators. Inductive edge sensors are used to provide feedback for global reconstruction of the mirror shape. The E-ELT M1 Local Control System will provide a deterministic infrastructure for collecting edge sensor and actuators readings and distribute the new position actuators references while at the same time providing failure detection, isolation and notification, synchronization, monitoring and configuration management. The present paper describes the prototyping activities carried out to verify the feasibility of the E-ELT M1 local control system communication architecture design and assess its performance and potential limitations.

The Mayall 4-meter telescope recently went through a major modernization of its telescope control system in preparation for DESI. We describe MPK (Mayall Pointing Kernel), our new software for telescope control. MPK outputs a 20Hz position-based trajectory with a velocity component, which feeds into Mayall’s new servo system over a socket. We wrote a simple yet realistic servo simulator that let us develop MPK mostly without access to real hardware, and also lets us provide other teams with a Mayall simulator as test bed for development of new instruments. MPK has a small core comprised of prioritized, soft real-time threads. Access to the core’s services is via MPK’s main thread, a complete, interactive Tcl/Tk shell, which gives us the power and flexibility of a scripting language to add any other features, from GUIs, to modules for interaction with critical subsystems like dome or guider, to an API for networked clients of a new instrument (e.g., DESI). MPK is designed for long term maintainability: it runs on a stock computer and Linux OS, and uses only standard, open source libraries, except for commercial software that comes with source code in ANSI C/C++. We discuss the technical details of how MPK combines the Reflexxes motion library with the TCSpk/TPK pointing library to generically handle any motion requests, from slews to offsets to sidereal or non-sidereal tracking. We show how MPK calculates when the servos have reached a steady state. We also discuss our TPOINT modeling strategy and report performance results.

The separation of science and engineering in the delivery of software systems overlooks the true nature of the problem being solved and the organization that will solve it. Use of a systems engineering approach to managing the requirements flow between these two groups as between a customer and contractor has been used with varying degrees of success by well-known entities such as the U.S. Department of Defense. However, treating science as the customer and engineering as the contractor fosters unfavorable consequences that can be avoided and opportunities that are missed. For example, the “problem” being solved is only partially specified through the requirements generation process since it focuses on detailed specification guiding the parties to a technical solution. Equally important is the portion of the problem that will be solved through the definition of processes and staff interacting through them. This interchange between people and processes is often underrepresented and under appreciated. By concentrating on the full problem and collaborating on a strategy for its solution a science-implementing organization can realize the benefits of driving towards common goals (not just requirements) and a cohesive solution to the entire problem. The initial phase of any project when well executed is often the most difficult yet most critical and thus it is essential to employ a methodology that reinforces collaboration and leverages the full suite of capabilities within the team. This paper describes an integrated approach to specifying the needs induced by a problem and the design of its solution.

The Giant Magellan Telescope (GMT)-Consortium Large Earth Finder (G-CLEF) is a fiber-fed, precision radial velocity (PRV) optical echelle spectrograph that will be the first light instrument on the GMT. The G-CLEF instrument device control subsystem (IDCS) provides software control of the instrument hardware, including the active feedback loops that are required to meet the G-CLEF PRV stability requirements. The IDCS is also tasked with providing operational support packages that include data reduction pipelines and proposal preparation tools. A formal, but ultimately pragmatic approach is being used to establish a complete and correct set of requirements for both the G-CLEF device control and operational support packages. The device control packages must integrate tightly with the state-machine driven software and controls reference architecture designed by the GMT Organization. A model-based systems engineering methodology is being used to develop a preliminary design that meets these requirements. Through this process we have identified some lessons that have general applicability to the development of software for ground-based instrumentation. For example, tasking an individual with overall responsibility for science/software/hardware integration is a key step to ensuring effective integration between these elements. An operational concept document that includes detailed routine and non- routine operational sequences should be prepared in parallel with the hardware design process to tie together these elements and identify any gaps. Appropriate time-phasing of the hardware and software design phases is important, but revisions to driving requirements that impact software requirements and preliminary design are inevitable. Such revisions must be carefully managed to ensure efficient use of resources.

The “Gran Telescopio de Canarias” (GTC) is an optical-infrared 10-meter segmented mirror telescope at the ORM observatory in Canary Islands (Spain). The GTC Control System (GCS) is a distributed object and component oriented system based on RT-CORBA and it is responsible for the operation of the telescope, including its instrumentation. The current development state of GCS is mature and fully operational. On the one hand telescope users as PI’s implement the sequences of observing modes of future scientific instruments that will be installed in the telescope and operators, in turn, design their own sequences for maintenance. On the other hand engineers develop new components that provide new functionality required by the system. This great work effort is possible to minimize so that costs are reduced, especially if one considers that software maintenance is the most expensive phase of the software life cycle. Could we design a system that allows the progressive assimilation of sequences of operation and maintenance of the telescope, through an automatic self-programming system, so that it can evolve from one Component oriented organization to a Service oriented organization? One possible way to achieve this is to use mechanisms of learning and knowledge consolidation to reduce to the minimum expression the effort to transform the specifications of the different telescope users to the operational deployments. This article proposes a framework for solving this problem based on the combination of the following tools: data mining, self-Adaptive software, code generation, refactoring based on metrics, Hierarchical Agglomerative Clustering and Service Oriented Architectures.

The use of Programmable Logic Controllers (PLCs) in the control of large physics experiments is ubiquitous^{1, 2, 3}. The programming of these controllers is normally the domain of engineers with a background in electronics, this paper introduces PLC program development from the software engineer's perspective. PLC programs provide the link between control software running on PC architecture systems and physical hardware controlled and monitored by digital and analog signals. The higher-level software running on the PC is typically responsible for accepting operator input and from this deciding when and how hardware connected to the PLC is controlled. The PLC accepts demands from the PC, considers the current state of its connected hardware and if correct to do so (based upon interlocks or other constraints) adjusts its hardware output signals appropriately for the PC's demands. A published ICD (Interface Control Document) defines the PLC memory locations available to be written and read by the PC to control and monitor the hardware. Historically the method of programming PLCs has been ladder diagrams that closely resemble circuit diagrams, however, PLC manufacturers nowadays also provide, and promote, the use of higher-level programming languages⁴. Based on techniques used in the development of high-level PC software to control PLCs for multiple telescopes, this paper examines the development of PLC programs to operate the hardware of a medical cyclotron beamline controlled from a PC using the Experimental Physics and Industrial Control System (EPICS), which is also widely used in telescope control^{5, 6, 7}. The PLC used is the new generation Siemens S7-1200 programmed using Siemens Pascal based Structured Control Language (SCL), which is their implementation of Structured Text (ST). The approach described is that from a software engineer's perspective, utilising Siemens Totally Integrated Automation (TIA) Portal integrated development environment (IDE) to create modular PLC programs based upon reusable functions capable of being unit tested without the PLC connected to hardware. Emphasis has been placed on designing an interface between EPICS and SCL that enforces correct operation of hardware through stringent separation of PC accessible PLC memory and hardware I/O addresses used only by the PLC. The paper also introduces the method used to automate the creation, from the same source document, the PLC memory structure (tag) definitions (defining memory used to access hardware I/O and that accessed by the PC) and creation of the PC program data structures (EPICS database records) used to access the permitted PLC addresses. From direct experience this paper demonstrates the advantages of PLC program development being shared between electronic and software engineers, to enable use of the most appropriate processes from both the perspective of the hardware and the higher-level software used to control it.

The Echelle SPectrograph for Rocky Exoplanets and Stable Spectral Observations (ESPRESSO) is an ultrastable spectrograph for the coudé-combined focus of the VLT. With its unprecedented capabilities (resolution up to fi 200,000, wavelength range from 380 to 780 nm; centimeter-per-second precision in wavelength calibration), ESPRESSO is a prime example of the now spreading science machine concept: a fully-integrated system carefully designed to perform direct scientific measurements on the data, in a matter of minutes from the execution of the observations. This approach is motivated by the very specific science cases of the instrument (search for terrestrial exoplanets with the radial velocity method; measure of the variation of fundamental constants using the spectral signatures of the inter-galactic medium) and is achieved by a dedicated tool for spectral analysis, the data analysis software or DAS, targeted to both stellar and quasar spectra. In this paper, we describe characteristics and performances of the DAS, with particular emphasis on the novel algorithms for stellar and quasar analysis (continuum fitting and interpretation of the absorption features).

Processing astronomical data to science readiness was and remains a challenge, in particular in the case of multi detector instruments such as wide-field imagers. One such instrument, the WIYN One Degree Imager, is available to the astronomical community at large, and, in order to be scientifically useful to its varied user community on a short timescale, provides its users fully calibrated data in addition to the underlying raw data. However, time-efficient re-processing of the often large datasets with improved calibration data and/or software requires more than just a large number of CPU-cores and disk space. This is particularly relevant if all computing resources are general purpose and shared with a large number of users in a typical university setup. Our approach to address this challenge is a flexible framework, combining the best of both high performance (large number of nodes, internal communication) and high throughput (flexible/variable number of nodes, no dedicated hardware) computing. Based on the Advanced Message Queuing Protocol, we a developed a Server-Manager- Worker framework. In addition to the server directing the work flow and the worker executing the actual work, the manager maintains a list of available worker, adds and/or removes individual workers from the worker pool, and re-assigns worker to different tasks. This provides the flexibility of optimizing the worker pool to the current task and workload, improves load balancing, and makes the most efficient use of the available resources. We present performance benchmarks and scaling tests, showing that, today and using existing, commodity shared- use hardware we can process data with data throughputs (including data reduction and calibration) approaching that expected in the early 2020s for future observatories such as the Large Synoptic Survey Telescope.

Gaia is a major European Space Agency (ESA) astrophysics mission designed to map and analyse 109 stars, ultimately generating more than 1 PetaByte of data-products. As Gaia data becomes publicly available and reaches a wider audience, there is an increasing need to facilitate the further use of Gaia products without needing to download large datasets. The Gaia Added Value Interface Platform (GAVIP) is designed to address this challenge by providing an innovative platform within which scientists can submit and deploy code, packaged as "Added Value Interfaces" (AVIs), which will be executed close to the data. Deployed AVIs and associated outputs may also be made available to other GAVIP platform users, thus providing a mechanism for scientific experiment reproducibility. This paper describes the capabilities and features of GAVIP.

This paper reports on the early investigation of using the work flow model for observatory infrastructure software. We researched several work ow engines and identified 3 for further detailed, study: Bonita BPM, Activiti and Taverna. We discuss the business process model and how it relates to observatory operations and identify a path finder exercise to further evaluate the applicability of these paradigms.

The WAS1(WEAVE Archive System) is a software architecture for archiving and delivering the data releases for the WEAVE7 instrument at WHT (William Herschel Telescope). The WEAVE spectrograph will be mounted at the 4.2-m WHT telescope and will provide millions of spectra in a 5-year program, starting early 2018. The access and retrieval of information will be through its dedicated archive, the WEAVE Archive System (WAS). This will be developed and maintained at the TNG2 premises on the same island as the WHT. Its structure foresees the main axes of scalability, virtualization, and high availability. We present here the first performances on a simulated data set of 20M spectra, using different architectures and hardware choices.

The increasing number of Very High Energy (VHE) sources discovered by the current generation of Cherenkov telescopes made particularly relevant the creation of a dedicated source catalogs as well as the cross-correlation of VHE and lower energy bands data in a multi-wavelength framework. The “TeGeV Catalog” hosted at the ASI Science Data Center (ASDC) is a catalog of VHE sources detected by ground-based Cherenkov detectors. The TeGeVcat collects all the relevant information publicly available about the observed GeV/TeV sources. The catalog contains also information about public light curves while the available spectral data are included in the ASDC SED Builder tool directly accessible from the TeGeV catalogue web page. In this contribution we will report a comprehensive description of the catalog and the related tools.

To achieve highly efficient observatory operations requires continuous evaluation and improvement of facility and instrumentation metrics. High quality metrics requires a foundation of robust and complete observatory telemetry. At the Large Binocular Telescope Observatory (LBTO), a variety of telemetry-capturing mechanisms exist, but few tools have thus far been created to facilitate studies of the data. In an effort to make all observatory telemetry data easy to use and broadly available, we have developed a suite of tools using in-house development and open source applications. This paper will explore our strategies for consolidating, parameterizing, and correlating any LBTO telemetry data to achieve easily available, web-based two- and three-dimensional time series data visualization.

Announced in 2012, started in 2013 and completed in 2015, the ALMA high bandwidth communication system has become a key factor to achieve the operational and scientific goals of ALMA. This paper summarizes the technical, organizational, and operational goals of the ALMA Optical Link Project, focused in the creation and operation of an effective and sustainable communication infrastructure to connect the ALMA Operations Support Facility and Array Operations Site, both located in the Atacama Desert in the Northern region of Chile, with the point of presence of REUNA in Antofagasta, about 400km away, and from there to the Santiago Central Office in the Chilean capital through the optical infrastructure created by the EC-funded EVALSO project and now an integral part of the REUNA backbone. This new infrastructure completed in 2014 and now operated on behalf of ALMA by REUNA, the Chilean National Research and Education Network, uses state of the art technologies, like dark fiber from newly built cables and DWDM transmission, allowing extending the reach of high capacity communication to the remote region where the Observatory is located. The paper also reports on the results obtained during the first year and a half testing and operation period, where different operational set ups have been experienced for data transfer, remote collaboration, etc. Finally, the authors will present a forward look of the impact of it to both the future scientific development of the Chajnantor Plateau, where many installations area are (and will be) located, as well as the potential Chilean scientific backbone long term development.

During operations, the ALMA observatory generates a huge amount of logs which contain not only valuable information related to specific failures but also for long term performance analysis. We implemented a big data solution based on Elasticsearch, Logstash and Kibana. They are configured as decoupled system which causes zero impact on the existent operations. It is able to keep more than six months of operation logs online. In this paper, we'll describe this infrastructure, applications built on top of it, and the problems that we faced during its implementation.

Despite significant advances in biological imaging and analysis, major informatics challenges remain unsolved: file formats are proprietary, storage and analysis facilities are lacking, as are standards for sharing image data and results. While the open FITS file format is ubiquitous in astronomy, astronomical imaging shares many challenges with biological imaging, including the need to share large image sets using secure, cross-platform APIs, and the need for scalable applications for processing and visualization. The Open Microscopy Environment (OME) is an open-source software framework developed to address these challenges. OME tools include: an open data model for multidimensional imaging (OME Data Model); an open file format (OME-TIFF) and library (Bio-Formats) enabling free access to images (5D+) written in more than 145 formats from many imaging domains, including FITS; and a data management server (OMERO). The Java-based OMERO client-server platform comprises an image metadata store, an image repository, visualization and analysis by remote access, allowing sharing and publishing of image data. OMERO provides a means to manage the data through a multi-platform API. OMERO’s model-based architecture has enabled its extension into a range of imaging domains, including light and electron microscopy, high content screening, digital pathology and recently into applications using non-image data from clinical and genomic studies. This is made possible using the Bio-Formats library. The current release includes a single mechanism for accessing image data of all types, regardless of original file format, via Java, C/C++ and Python and a variety of applications and environments (e.g. ImageJ, Matlab and R).

We discuss Generalised Least Squares (GLS) map-making for the data of the Herschel satellite’s photometers, which is a difficult task, due to the many disturbances affecting the data, and requires appropriate pre- and post-processing. Taking an existing map-maker as a reference, we propose several advanced techniques, which can improve both the quality of the estimate and the efficiency of the software. As a main contribution we discuss two disturbances, which have not been studied yet and may be detrimental to the image quality. The first is a data shift, due to delays in the timing system or in the processing chain. The second is a random noise, termed pixel noise, due to the jitter and the approximation of the pointing information. For both these disturbances, we develop a mathematical model and propose a compensation method. As an additional contribution, we note that the performance can be improved by properly adapting the algorithm parameters to the data being processed and discuss an automatic setting method. We also provide a rich set of examples and experiments, illustrating the impact of the proposed techniques on the image quality and the execution speed.

We present the current status of the design of the science data reduction pipeline and the corresponding dataflow system for METIS. It will be one of the first three instruments for the E-ELT and work at wavelengths between 3-19 μm (L/M/N/Q1 bands). We will deliver software which is compliant to standards of the European Southern Observatory (ESO), and will employ state of the art techniques to produce science grade data, master calibration frames, quality control parameters and to handle instrument effects. The Instrument currently offers a wealth of observing modes that are listed in this paper. Data reduction for a ground based instrument at these wavelengths is particularly challenging because of the massive influence of thermal radiation from various sources. We will give a comprehensive overview of the data ow system for the imaging modes that the instrument offers and discuss a single recipe versus a multi recipe approach for the different observing modes for imaging.

This contribution describes both the design and the implementation details of a new solution for publishing VO services, enlightening its maintainable, distributed, modular and scalable architecture. Indeed, the new publisher is multithreaded and multiprocess. Multiple instances of the modules can run on different machines to ensure high performance and high availability, and this will be true both for the interface modules of the services and the back end data access ones. The system uses message passing to let its components communicate through an AMQP message broker that can itself be distributed to provide better scalability and availability.

The TNG-INAF is developing the science archive for the WEAVE instrument. The underlying architecture of the archive is based on a non relational database, more precisely, on Apache Cassandra cluster, which uses a NoSQL technology. In order to test and validate the use of this architecture, we created a local archive which we populated with all the HARPSN spectra collected at the TNG since the instrument's start of operations in mid-2012, as well as developed tools for the analysis of this data set. The HARPS-N data set is two orders of magnitude smaller than WEAVE, but we want to demonstrate the ability to walk through a complete data set and produce scientific output, as valuable as that produced by an ordinary pipeline, though without accessing directly the FITS files. The analytics is done by Apache Solr and Spark and on a relational PostgreSQL database. As an example, we produce observables like metallicity indexes for the targets in the archive and compare the results with the ones coming from the HARPS-N regular data reduction software. The aim of this experiment is to explore the viability of a high availability cluster and distributed NoSQL database as a platform for complex scientific analytics on a large data set, which will then be ported to the WEAVE Archive System (WAS) which we are developing for the WEAVE multi object, fiber spectrograph.

Subaru Telescope, an 8-meter class optical telescope located in Hawaii, has been using a high-availability commodity cluster as a platform for our Observation Control System (OCS). Until recently, we have followed a tried-and-tested practice of running the system under a native (Linux) OS installation with dedicated attached RAID systems and following a strict cluster deployment model to facilitate failover handling of hardware problems,1.2 Following the apparent benefits of virtualizing (i.e. running in Virtual Machines (VMs)) many of the non- observation critical systems at the base facility, we recently began to explore the idea of migrating other parts of the observatory's computing infrastructure to virtualized systems, including the summit OCS, data analysis systems and even the front ends of various Instrument Control Systems. In this paper we describe our experience with the initial migration of the Observation Control System to virtual machines running on the cluster and using a new generation tool – ansible - to automate installation and deployment. This change has significant impacts for ease of cluster maintenance, upgrades, snapshots/backups, risk-management, availability, performance, cost-savings and energy use. In this paper we discuss some of the trade-offs involved in this virtualization and some of the impacts for the above-mentioned areas, as well as the specific techniques we are using to accomplish the changeover, simplify installation and reduce management complexity.

The Cherenkov Telescope Array (CTA) represents the next generation of ground-based observatories for very high energy gamma-ray astronomy. The CTA will consist of two arrays at two different sites, one in the northern and one in the southern hemisphere. The current CTA design foresees, in the southern site, the installation of many tens of imaging atmospheric Cherenkov telescopes of three different classes, namely large, medium and small, so defined in relation to their mirror area; the northern hemisphere array would consist of few tens of the two larger telescope types. The Italian National Institute for Astrophysics (INAF) is developing the Cherenkov Small Size Telescope ASTRI SST- 2M end-to-end prototype telescope within the framework of the International Cherenkov Telescope Array (CTA) project. The ASTRI prototype has been installed at the INAF observing station located in Serra La Nave on Mt. Etna, Italy. Furthermore a mini-array, composed of nine of ASTRI telescopes, has been proposed to be installed at the Southern CTA site. Among the several different infrastructures belonging the ASTRI project, the Information and Communication Technology (ICT) equipment is dedicated to operations of computing and data storage, as well as the control of the entire telescope, and it is designed to achieve the maximum efficiency for all performance requirements. Thus a complete and stand-alone computer centre has been designed and implemented. The goal is to obtain optimal ICT equipment, with an adequate level of redundancy, that might be scaled up for the ASTRI mini-array, taking into account the necessary control, monitor and alarm system requirements. In this contribution we present the ICT equipment currently installed at the Serra La Nave observing station where the ASTRI SST-2M prototype will be operated. The computer centre and the control room are described with particular emphasis on the Local Area Network scheme, the computing and data storage system, and the telescope control and monitoring.

Radio Astronomical Data models are becoming very complex since the huge possible range of instrumental configurations available with the modern Radio Telescopes. What in the past was the last frontiers of data formats in terms of efficiency and flexibility is now evolving with new strategies and methodologies enabling the persistence of a very complex, hierarchical and multi-purpose information. Such an evolution of data models and data formats require new data archiving techniques in order to guarantee data preservation following the directives of Open Archival Information System and the International Virtual Observatory Alliance for data sharing and publication. Currently, various formats (FITS, MBFITS, VLBI's XML description files and ancillary files) of data acquired with the Medicina and Noto Radio Telescopes can be stored and handled by a common Radio Archive, that is planned to be released to the (inter)national community by the end of 2016. This state-of-the-art archiving system for radio astronomical data aims at delegating as much as possible to the software setting how and where the descriptors (metadata) are saved, while the users perform user-friendly queries translated by the web interface into complex interrogations on the database to retrieve data. In such a way, the Archive is ready to be Virtual Observatory compliant and as much as possible user-friendly.

The Cherenkov Telescope Array (CTA) represents the next generation of ground based observatories for very high energy gamma ray astronomy. The CTA will consist of two arrays at two different sites, one in the northern and one in the southern hemisphere. The current CTA design foresees, in the southern site, the installation of many tens of imaging atmospheric Cherenkov telescopes of three different classes, namely large, medium, and small, so defined in relation to their mirror area; the northern hemisphere array would consist of few tens of the two larger telescope types. The telescopes will be equipped with cameras composed either of photomultipliers or silicon photomultipliers, and with different trigger and read-out electronics. In such a scenario, several different methods will be used for the telescopes’ calibration. Nevertheless, the optical throughput of any CTA telescope, independently of its type, can be calibrated analyzing the characteristic image produced by local atmospheric highly energetic muons that induce the emission of Cherenkov light which is imaged as a ring onto the focal plane if their impact point is relatively close to the telescope optical axis. Large sized telescopes would be able to detect useful muon events under stereo coincidence and such stereo muon events will be directly addressed to the central CTA array data acquisition pipeline to be analyzed. For the medium and small sized telescopes, due to their smaller mirror area and large inter-telescope distance, the stereo coincidence rate will tend to zero; nevertheless, muon events will be detected by single telescopes that must therefore be able to identify them as possible useful calibration candidates, even if no stereo coincidence is available. This is the case for the ASTRI telescopes, proposed as pre-production units of the small size array of the CTA, which are able to detect muon events during regular data taking without requiring any dedicated trigger. We present two fast algorithms to efficiently use uncalibrated data to recognize useful muon events within the single ASTRI camera server while keeping the number of proton induced triggers as low as possible to avoid saturating the readout budget towards the central CTA data analysis pipeline.

The "Gran Telescopio Canarias" (GTC) is an optical-infrared 10-meter segmented mirror telescope at the Observatorio del Roque de los Muchachos (ORM) observatory in Canary Islands (Spain). The GTC Control System (GCS) is continuously evolving to enhance the operational efficiency. In this work we present the new GCS subsystem to automatize the guiding setup process, both for Fast Guiding and for Slow Guiding. A set of restrictions (including vignetting and photometric computations) is used to select the stars appropriate for guiding, and a merit function is used to choose the best one. Then, the system computes the optical configuration that fits best the selected star, automatically performs the guide star acquisition process and it closes the guide loop.

LMU Munchen operates an astrophysical observatory on Mt. Wendelstein1. The 2m Fraunhofer telescope^{2, 3} is equipped with a 0.5 x 0.5 square degree field-of-view wide field camera⁴ and a 3 channel optical/NIR camera^{5, 6}. Two fiber coupled spectrographs^7-9 and a wavefront sensor will be added in the near future. The observatory hosts a multitude of supporting hardware, i.e. allsky cameras, webcams, meteostation, air conditioning etc. All scientific hardware can be controlled through a single, central "Master Control Program" (MCP). At the last SPIE astronomy venue we presented the overall Wendelstein Observatory software concept¹⁰. Here we explain concept and implementation of the MCP as a multi-threaded Python daemon in the area of conflict between debuggability and Don't Repeat Yourself (DRY).

ESPRESSO, the Echelle SPectrograph for Rocky Exoplanet and Stable Spectroscopic Observations of the ESO - Very Large Telescope site, is now in its integration phase. The large number of functions of this complex instrument are fully controlled by a Beckhoff PLC based control electronics architecture. Four small and one large cabinets host the main electronic parts to control all the sensors, motorized stages and other analogue and digital functions of ESPRESSO. The Instrument Control Electronics (ICE) is built following the latest ESO standards and requirements. Two main PLC CPUs are used and are programmed through the TwinCAT Beckhoff dedicated software. The assembly, integration and verification phase of ESPRESSO, due to its distributed nature and different geographical locations of the consortium partners, is quite challenging. After the preliminary assembling and test of the electronic components at the Astronomical Observatory of Trieste and the test of some electronics and software parts at ESO (Garching), the complete system for the control of the four Front End Unit (FEU) arms of ESPRESSO has been fully assembled and tested in Merate (Italy) at the beginning of 2016. After these first tests, the system will be located at the Geneva Observatory (Switzerland) until the Preliminary Acceptance Europe (PAE) and finally shipped to Chile for the commissioning. This paper describes the integration strategy of the ICE workpackage of ESPRESSO, the hardware and software tests that have been performed, with an overall view of the experience gained during these project’s phases.

In the framework of the international Cherenkov Telescope Array (CTA) observatory, the Italian National Institute for Astrophysics (INAF) has developed a dual mirror, small sized, telescope prototype (ASTRI SST-2M), installed in Italy at the INAF observing station located at Serra La Nave, Mt. Etna. The ASTRI SST-2M prototype is the basis of the ASTRI telescopes that will form the mini-array proposed to be installed at the CTA southern site during its preproduction phase. This contribution presents the solutions implemented to realize the monitoring system for the Information and Communication Technology (ICT) infrastructure of the ASTRI SST-2M prototype. The ASTRI ICT monitoring system has been implemented by integrating traditional tools used in computer centers, with specific custom tools which interface via Open Platform Communication Unified Architecture (OPC UA) to the Alma Common Software (ACS) that is used to operate the ASTRI SST-2M prototype. The traditional monitoring tools are based on Simple Network Management Protocol (SNMP) and commercial solutions and features embedded in the devices themselves. They generate alerts by email and SMS. The specific custom tools convert the SNMP protocol into the OPC UA protocol and implement an OPC UA server. The server interacts with an OPC UA client implemented in an ACS component that, through the ACS Notification Channel, sends monitor data and alerts to the central console of the ASTRI SST-2M prototype. The same approach has been proposed also for the monitoring of the CTA onsite ICT infrastructures.

The Square Kilometre Array (SKA) is an ambitious project aimed to build a radio telescope that will enable breakthrough science not possible with current facilities over the next 50 years. Because of this long expected operational period, the maintenance of Telescope Manager (TM), the SKA Element responsible for the coordination of all Elements composing the Telescope (e.g. Dishes for mid-frequency or Low-Frequency Aperture Arrays), plays a crucial role for the overall SKA operation. A challenge is represented by the technological evolution in hardware and software, which is rather fast nowadays: only in the last 10 years, for instance, new operating systems were born, as well as new technologies for data storage and for calculation. Dealing with such changing environment deserves therefore a deep analysis in terms of maintenance. In spite of the importance of hardware maintenance for TM, its software maintenance is actually the real challenge, given TM is a system almost entirely composed by software applications. In computer science, indeed, it is almost impossible to build a software which does not need to be changed over time: new requirements emerge, old requirements change during application lifetime, errors are discovered or performance must be improved. For all these reasons the management of software changes is critical to maintain the value of the software developed, especially for a complex system like SKA TM. In this paper the maintenance for both SKA TM hardware and software is presented with respect to the Operational (i.e. related to Maintenance Process) and Organizational (i.e. related to Logistic Support) aspects.

The Echelle Spectrograph for Rocky Exoplanets and Stable Spectral Observations (ESPRESSO) requires active-loop stabilization of the light path from the telescope to the spectrograph, in order to achieve its centimeter-per- second precision goal. This task is accomplished by moving the mirrors placed along the light path by means of piezoelectric actuators. Two cameras are used to acquire the field and pupil images, and the required corrections are dynamically calculated and applied to the piezos. In this paper we will discuss the camera usage, performance and network bandwidth requirements for the ESPRESSO scientific operations.

The Square Kilometre Array (SKA) will be the world's most advanced radio telescope, designed to be many times times more sensitive and hundreds of times faster at mapping the sky than today's best radio astronomy facilities. The scale and advanced capabilities of the SKA present technical challenges for co-ordinating and executing observations. This paper discusses the requirements placed on the SKA's observation sequencer - the Observation Execution Tool - and the functions it must perform. A design and prototype implementation of the Observation Execution Tool are presented, with initial results showing that a Python implementation using a message-driven component architecture could be capable of meeting the SKA's requirements.

Fighting vibrations on large telescopes is an arduous task. At Gemini, vibrations originating from cryogenic coolers have been shown to degrade the optical wavefront, in certain cases by as much as 40%. This paper discusses a general solution to vibration compensation by tracking the real time vibration state of the telescope and using M2 to apply corrections. Two approaches are then presented: an open loop compensation at M2 based on the signal of accelerometers at the M1 glass, and a closed loop compensation at M2 based on optical measurements from the wave front sensor. The paper elaborates on the pros and cons of each approach and the challenges faced during commissioning. A conclusion is presented with the final results of vibration tracking integrated with operations.

This paper reports on progress and plans for all meta-components of the Large Synoptic Survey Telescope (LSST) observatory control system (OCS). After an introduction to the scope of the OCS we discuss each meta- component in alphabetical order: application, engineering and facility database, maintenance, monitor, operator- remote, scheduler, sequencer, service abstraction layer and telemetry. We discuss these meta-components and their relationship with the overall control and operations strategy for the observatory. At the end of the paper, we review the timeline and planning for the delivery of these items.

The Mid-resolution InfRAreD Astronomical Spectrograph (MIRADAS) is a near-infrared multi-object echelle spectrograph for the 10.4-meter Gran Telescopio Canarias. The instrument has 12 pickoff mirror optics on cryogenic probe arms, enabling it to concurrently observe up to 12 user-defined objects located in its field-of-view. In this paper, a method to compute collision-free trajectories for the arms of MIRADAS is presented. We propose a sequential approach that has two stages: target to arm assignment and motion planning. For the former, we present a model based on linear programming that allocates targets according to their associated priorities. The model is constrained by two matrices specifying the targets’ reachability and the incompatibilities among each pair of feasible target-arm pairs. This model has been implemented and experiments show that it is able to determine assignments in less than a second. Regarding the second step, we present a prioritized approach which uses sampled-based roadmaps containing a variety of paths. The motions along a given path are coordinated with the help of a depth-first search algorithm. Paths are sequentially explored according to how promising they are and those not leading to a solution are skipped. This motion planning approach has been implemented considering real probe arm geometries and joint velocities. Experimental results show that the method achieves good performance in scenarios presenting two different types of conflicts.

The new Gemini High Resolution Optical Spectrograph (GHOST) will be controlled with software developed against the new Gemini software framework - the Gemini Instrument Application Programmer Interface (GIAPI). The developers describe their experience using this framework and compare it to control systems developed for earlier Gemini instruments using the original Gemini Core Instrument Control System (CICS) framework.

High-energy muons constitute a very useful tool to calibrate the total optical throughput of any telescope of the Cherenkov Telescope Array (CTA). Differences in precision and efficiency can however be present due to the variety of telescope types and sizes. In this contribution we present some preliminary results on simulated muon ring images collected by the ASTRI small sized dual-mirror (SST-2M) telescope in the basic configuration installed in Italy at the Serra La Nave observing station. ASTRI SST-2M is able, using 6% of the detected muon events, to calibrate with muons the optical throughput down to a degradation of the optical efficiency of 30%. Moreover, its precision in reconstructing the muon arrival direction is about one camera pixel, and its error on the reconstructed ring radius is ~ 6.3%. The adopted procedures will be tested and validated with real data acquired by the prototype after the commissioning phase. The nine telescopes that will form the ASTRI mini-array, proposed to be installed at the final CTA southern site during the pre-production phase, will improve these results thanks to the higher detection efficiency and the lower optical cross-talk and after-pulse of their updated silicon photomultipliers.

The INO340 stands for Iranian National Observatory, which is an Alt-Az reflecting optical telescope with 3.4m main mirror diameter. At the moment, the conceptual design of telescope control system (TCS) has been finished and the detailed design is developing. Distributed control system configuration has been selected for the architecture of TCS design. TCS is responsible for the control of the telescope structure with its mirrors including 3 major subsystems: TCSS, MCS and AOS. All subsystems of TCS are designed with an adequate safety subsystem. This paper presents the TCS architecture of INOCS, and then it focuses on the requirements and the major functionalities of MCS. We provide different analysis of MCS using related parameters such as wind effect, encoder resolution and etc. Based on the simulation results the optimum sets of parameters and functions of different modules are concluded. The Alt balancing and mirror cover sub-systems are also briefly presented. Finally, we present the evaluation results of MCS design based on the pre-defined telescope requirements.

RTS2 is an open source observatory control system. Being developed from early 2000, it continue to receive new features in last two years. RTS2 is a modulat, network-based distributed control system, featuring telescope drivers with advanced tracking and pointing capabilities, fast camera drivers and high level modules for ”business logic” of the observatory, connected to a SQL database. Running on all continents of the planet, it accumulated a lot to control parts or full observatory setups.

Astronomical observatories are complex systems requiring the integration of numerous devices into a common platform. We are presenting here the firsts steps to integrate the popular Robotic Operating System (ROS) into the control of a fully autonomous observatory. The observatory is also equipped with a decision-making procedure that can automatically react to a changing environment (like weather events). The results obtained so far have shown that the automation of a small observatory can be greatly simplified when using ROS, as well as robust, with the implementation of our decision-making algorithms.

The CHaracterising ExOPlanet Satellite (CHEOPS) is the first ESA S-class and exoplanetary follow-up mission headed for launch in 2018. It will perform ultra-high-precision photometry of stars hosting confirmed exoplanets on a 3-axis stabilised sun-synchronous orbit that is optimised for uninterrupted observations at minimum stray light and thermal variations. Nevertheless, due to the satellites structural design, the alignment of the star trackers and the payload instrument telescope is affected by thermo-elastic deformations. This causes a high pointing uncertainty, which requires the payload instrument to provide an additional acquisition system for distinct target identification. Therefor a star extraction software and two star identification algorithms, originally designed for star trackers, were adapted and optimised for the special case of CHEOPS. In order to evaluate these algorithms reliability, thousands of random star configurations were analysed in Monte-Carlo simulations. We present the implemented identification methods and their performance as well as recommended parameters that guarantee a successful identification under all conditions.

We present an integrated end-end simulation of the spectral images that will be obtained by the weave spectrograph, which aims to include full modelling of all effects from the top of the atmosphere to the detector. These data are based in input spectra from a combination of library spectra and synthetic models, and will be used to provide inputs for an endend test of the full weave data pipeline and archive systems, prior to 1st light of the instrument.

The Square Kilometer Array (SKA) project is an international effort to build the world's largest radio telescope, with eventually over a square kilometer of collecting area. For SKA Phase 1, Australia will host the low-frequency instrument with more than 500 stations, each containing around 250 individual antennas, whilst South Africa will host an array of close to 200 dishes. The scale of the SKA represents a huge leap forward in both engineering and research and development towards building and delivering a unique instrument, with the detailed design and preparation now well under way. As one of the largest scientific endeavors in history, the SKA will brings together close to 100 organizations from 20 countries. Every aspect of the design and development of such a large and complex instrument requires state-of-the-art technology and innovative approach. This poster (or paper) addresses some aspects of the SKA monitor and control system, and in particular describes the development and test results of the CSP Local Monitoring and Control prototype. At the SKA workshop held in April 2015, the SKA monitor and control community has chosen TANGO Control System as a framework, for the implementation of the SKA monitor and control. This decision will have a large impact on Monitor an Control development of SKA. As work is on the way to incorporate TANGO Control System in SKA is in progress, we started to development a prototype for the SKA Central Signal Processor to mitigate the associated risks. In particular we now have developed a uniform class schema proposal for the sub-Element systems of the SKA-CSP.

We have prepared remote observing environment for the 188 cm telescope at Okayama Astrophysical Observatory. A KVM-over-IP and a VPN gateway are employed as core devices, which offer reliable, secure and fast link between on site and remote sites. We have confirmed the KVM-over-IP has ideal characteristics for serving the remote observing environment; the use is simple for both users and maintainer; access from any platform is available; multiple and simultaneous access is possible; and maintenance load is small. We also demonstrated that the degradation of observing efficiency specific to the remote observing is negligibly small. The remote observing environment has fully opened since the semester 2016A, about 30% of the total observing time in the last semester was occupied by remote observing.

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.