The Square Kilometre Array Observatory (SKAO) project aims to develop scientific and control software within a collaboration involving more than 30 teams distributed worldwide. The agile method tailored for large collaborations known as SAFe (Scaled Agile Framework) has been adopted to manage such a complex scenario. SAFe provides principles and practices for coordination among various teams involved in the incremental development of software, ensuring a global view of the project status at the individual team and program board levels. The CREAM team is a specialized team responsible for developing both the Local Monitoring and Control software of the Central Signal Processing (CSP.LMC) subsystem and the web graphical interface named Taranta. Within the team, it was observed that, in some cases, Taranta’s features released according to the Definition of Done (DoD) criteria and in alignment with the management’s requests did not fully meet user needs when adopted by teams. The lack of a process allowing for the reconsideration and redevelopment of features, coupled with uncertainty about when these issues could be addressed within the Program Increment, led teams to either underutilize or lose confidence in the whole software. A hypothesis is that the problem could be due to a missing beta testing process for features at the time of release. In the implemented SAFe process, features are demonstrated at the time of release during a system demo, and the team can make limited adjustments based on feedback collected during the session, typically constrained as they are usually already working on another feature. This paper suggests an approach to conduct beta tests that is well integrated within the SAFe framework and specifically its two-level iterations: quarterly and be-weekly ones. The challenges are being able to spend enough time exploring and detecting UX issues (through a beta testing process) and delivering a solution within consecutive sprints, but still adhering to the DoD. The paper outlines the steps for selecting beta users, the types of tests conducted, how feedback was collected and the final considerations. We believe this approach, testing with small groups of SKAO personnel, can be standardized for potential adoption across all the SKAO teams, and potentially also by other large scientific projects that rely on agile development methods.
The Taranta project, a collaboration between the MAX IV Institute and Square Kilometre Array (SKAO) within the Tango Collaboration, presents a web-based, no-code approach for creating graphical interfaces dedicated to monitoring and controlling Tango-based systems. Through an active development phase and close collaboration with the community, the software has seen the introduction of advanced features and a code refactor to enhance functionality, user experience, performance, and testability. Currently, the software has matured to a level enabling adoption in both the daily operations of MAX IV synchrotron beamlines and the developmental phases of the SKA project. It is also used within the Tango community. To facilitate users in increasingly comprehensive utilization, new features have been implemented, such as the ability to access devices from different Tango databases within a single dashboard. Architectural improvements have also been made to seamlessly integrate applications like Synoptic into Taranta. Additional developments and improvements have been introduced in response to user needs. Beyond these aspects, the presentation will delve into one of the most significant challenges faced—meeting the demands from institutes with diverse scientific purposes and project stages. This encompasses considerations of architecture, component numbers, and operator skill sets. The presentation will then delve into lessons learned, emphasizing the importance of adaptability and continuous improvement in a dynamic collaborative environment. The strategy for defining the roadmap will be discussed, with a focus on producing increasingly comprehensive GUIs tailored to the specific requirements of the users.
The Square Kilometre Array (SKA) Central Signal Processor (CSP) is a real-time backend system that processes incoming astronomical signals to produce visibilities and detects and profiles pulsars. The CSP is composed of the Local Monitoring and Control (LMC), the Correlator and Beam-Former (CBF), and the Pulsar Search and Timing (PSS, PST) engines. Each subsystem is developed by a different team in the SKA control software domain following the Scaled Agile Framework (SAFe) to guarantee coherence in the development. The definition of an engineering User Interface (UI) for the CSP is challenging due to the variety of skills that are required to identify the most relevant design concepts and potential roadblocks to an effective representation and the fact that several teams are involved. For this reason, we chose to leverage a collaborative design approach that can easily fit SKA’s biweekly sprint cadence while involving experts from different fields in a “think outside the box” process. Sketches and wireframes undergo multiple refinement sessions that lead to the realization of an engineering dashboard representing the current state of CSP implementation. User testing sessions constitute the means by which the success of the proposed UI is measured. Additional positive effects are alignment across different teams on the current capabilities of the system and its future development, as well as a way for continuously adapting the UI to the system’s evolution. In this paper, we describe the challenges we faced while coordinating the design across multiple teams, show how the process was implemented to fit the short agile iterations and overall SAFe framework and present the results of the work.
The AZT24 is a 1.1m telescope installed at the Campo Imperatore observing station, in Central Italy, at an elevation of 2200 m a.s.l. Since the 2nd half of 1990s, its focal plane has been equipped with SWIRCAM, a 1-2.5 micron camera based on an LN2-cooled, HgCdTe detector, able to exploit the excellent observing conditions offered by the site, especially at those wavelengths. After almost 30 years of operation, this system will now be upgraded with a new IR imager, based on an InGaAs detector, TEC-cooled at around -80 °C. Even with a reduced spectral coverage, the NIR imager will cover a wider field-of-view and will benefit from the seeing-enhancement capability produced by a devoted Tip-Tilt (TT) corrector. The overall project is presented in this paper, with emphasis on a commercial InGaAs detector for astronomical applications. The opto-mechanical layout is optimized to reduce the instrumental thermal background, while the TT-correction system produces a significant narrowing of the PSF, increasing the signal-to-noise ratio of the detected sources. Simulations of the expected performances are reported: they show that the upgraded system is suitable for a number of science cases, ranging from extragalactic Astronomy to stellar Astrophysics and Solar System studies. In addition, it represents an interesting testbench for some technological investigations, both in the field of Adaptive Optics and in that of data acquisition and processing techniques.
Square Kilometer Array (SKA) is a project aimed to build the largest radio telescope in the world and it has just gotten into the construction phase. In this phase, the ability to develop and integrate software in an integration environment is crucial as it is the ability to visualize system-related information via a User Interface to rapidly verify the correctness of the system behavior and spot any anomaly. This is achieved by SKA teams thanks to the deployment of the Taranta suite in the integration environment. Taranta suite is a web-based toolset jointly developed by MAX IV Laboratory and the SKA that allows the fast development of graphical user interfaces connected to TANGO devices, based on a set of predefined widgets and a drag-and-drop mechanism and therefore without the need to write any additional code. In this paper, we present the Taranta general architecture and the main widgets currently available, we describe how the Taranta suite is deployed in the SKA integration environment and we explain the process used to collect feedback from the SKA community to define the roadmap for the future development of the tool.
The SKA requires a comprehensive suite of applications to be prototyped in the current 'bridging' phase ahead of the formal start of construction, leading to full development in the subsequent construction phase. The Scaled Agile Framework (SAFe R) has become an industry standard process for managing the development of large software systems, defining a set of processes to manage and coordinate the activity of multiple agile software development teams. SAFe has been adopted by the SKA, and is being used to coordinate a large number of globally distributed agile development teams; including the team developing prototypes of the Observatory Science Operation (OSO) applications. Much of the team who developed the OSO design for Critical Design Review (CDR) are now involved in the agile development of the OSO tools, and with the shift to SAFe development have a unique view on how to develop within SAFe from a plan that was developed anticipating a traditional waterfall software development process. Here we present an overview of how evolutionary prototypes of these tools (from proposal handling and assessment, through to observation design, planning, scheduling and execution) are being developed for the SKA within SAFe.
SKA Construction phase we are now in a transition phase that hopefully will prepare us for the next challenge: start building the SKA. One of the targets of this period is to evaluate the suitability of the Taranta (proper Webjive) Suite for creating engineering User Interfaces (UIs). The Taranta suite is a framework that allows the fast creation of web UIs that directly communicate with TANGO devices. What we need to address are the answers to questions such as: What kind of interface are you targeting? What are the performance constraints that you foresee? What are the current limitations of the tool that would make you choose a different one instead? What will the context of use be? What kind of features would you like the tool to have?
One basic system requirement for the SKA Project is aimed to providing both a rolled-up and a drilled-down view of the Operational (Health) Status, as well as the State, for each Element. The first one is a performance indicator that must be properly structured in order an operator can understand it. The second one is a logic enumerative that has to contain at least the following values: start-up, shutdown, standby and operational. In this paper an aggregation algorithm, defined for the Health Status of the SKA Telescope Manager (TM) but abstract enough in order to be extended to a generic complex system, is analyzed in terms of the three main indications it has to provide: fully operating, degraded performance, faulty. The analysis shows that the distinction among critical and non-critical components, along with their state and weight on the overall system, is enough to completely achieve a rolled-up view of the system. System architecture only affects the weights, which are the result of a dependability analysis initially performed on the system itself. The aggregation can be applied to selected subsets of components, so providing hints for a drilling-down of the monitoring data, when this is necessary. Finally, using the algorithm to aggregate the states essentially fails: a different approach based on logic relationships will have to be adopted in order to manage states, but to this purpose an important role can be played by the aggregated health status.
KEYWORDS: Computing systems, Telescopes, Data storage, Antennas, Data processing, Databases, Computer architecture, Signal processing, Data archive systems, Data centers
The Square Kilometer Array (SKA) Telescope, is an ongoing project set to start its building phase in 2018 and be ready for first light in 2020. The first part of the project, the SKA1 will be comprised of 130.000 low frequency antennas (50 MHz to 350 MHz) and 200 mid frequency antennas (350 MHz to 15.5 GHz). The SKA1 will produce a raw data rate of ~10 Tb/s, require a computing power of 100 Pflop/s and an archiving capacity of hundreds of PB/year. The next phase of the project, the SKA2, is going to increase the number of both low and mid antennas by a factor of 10 and increase the computing requirements accordingly. The key requirements for the project are a very demanding availability of 99.9%, computing scalability and result reproducibility. We propose an approach to enforce these requirements - with an optimal use of resources - by using highly distributed computing and virtualization technologies.
KEYWORDS: Databases, Data modeling, Data archive systems, Control systems, Data storage, Analytics, Computer architecture, Cameras, Standards development, Instrument modeling
The TANGO controls framework community has put a lot of effort in creating the HDB++ software system that is an high performance, event-driven archiving system. Its design allows storing data into traditional database management systems such as MySQL as well as NoSQL database such as Apache Cassandra. The architecture allow also to easily extend it to other noSql database like, for instance, ELK. This paper describes the step needed to extend the HDB++ and explore the possibilities to use the ELK technology in term of analysis being enabled and tools provided.
The international Square Kilometre Array (SKA) project to build two radio interferometers is approaching the end of its design phase, and gearing up for the beginning of formal construction. A key part of this distributed Observatory is the overall software control system: the Telescope Manager (TM). The two telescopes, a Low frequency dipole array to be located in Western Australia (SKA-Low) and a Mid-frequency dish array to be located in South Africa (SKA-Mid) will be operated as a single Observatory, with its global headquarters (GHQ) based in the United Kingdom at Jodrell Bank. When complete it will be the most powerful radio observatory in the world. The TM software must combine the observatory operations based at the GHQ with the monitor and control operations of each telescope, covering the range of domains from proposal submission to the coordination and monitoring of the subsystems that make up each telescope. It must also monitor itself and provide a reliable operating platform. This paper will provide an update on the design status of TM, covering the make-up of the consortium delivering the design, a brief description of the key challenges and the top level architecture, and its software development plans for tackling the construction phase of the project. It will also briefly describe the consortium’s response to the SKA Project’s decision in the second half of 2016 to adopt the processes set out by the Software Engineering Institute (SEI) for system architecture design and documentation, including a re-evaluation of its deliverables, documentation and approach to internal reviews.
Adopting the recommendations for the control room obtained by a user-centered design approach for the Square Kilometer Array (SKA), the following characteristics for the SKA Graphical User Interface (GUI) have been identified: scalability, integrated tools, extendability and completeness. The lack of one or more of these characteristics could lead to usability problems like low user’s efficiency, high error rate, high user’s mental load and user’s frustration. In this paper one of the most recent web technologies that enable the user-centered design are analyzed. TangoWebApp, a pluggable web platform integrated with TANGO Control REST API, appears very suitable also taking into account the adoption of TANGO as the SKA control framework. Starting from a SKA Telescope Manager (TM) Services use case, a prototype has been developed composed by a series of TANGO WebApp plugins that allow the operator to correctly and efficiently complete the tasks of the scenario. Some of the plugins, in particular, have been developed to extend the functionalities of the TANGO WebApp itself to make it fully compliant with the User Centered Design. As a result of this work, the TangoWebapp proved itself not only fully compliant with the User Centered Design, but also flexible enough to add functionalities in the form of properly developed plugins. These characteristics of the TangoWebapp, together with its unique feature to be integrated into TANGO, make it a good candidate to be the SKA GUI platform.
The SKA project is an international effort (10 member and 10 associated countries with the involvement of 100 companies and research institutions) to build the world’s largest radio telescope. The SKA Telescope Manager (TM) is the core package of the SKA Telescope aimed at scheduling observations, controlling their execution, monitoring the telescope and so on. To do that, TM directly interfaces with the Local Monitoring and Control systems (LMCs) of the other SKA Elements (for example, Dishes, Correlator and so on), exchanging commands and data with them by using the TANGO controls framework (see [1]). TM in turn needs to be monitored and controlled, in order its continuous and proper operation is ensured and this higher responsibility has been assigned to the TM SER package.
KEYWORDS: Telescopes, Control systems, Control systems, Chemical elements, Data centers, Data modeling, Signal processing, Databases, Logic devices, Data storage, Diagnostics
The SKA Telescope Manager (TM) is the core package of the SKA Telescope: it is aimed at scheduling observations, controlling their execution, monitoring the telescope health status, diagnosing and fixing its faults and so on. To do that, TM directly interfaces with the Local Monitoring and Control systems (LMCs) of the various SKA Elements (e.g. Dishes, Low-Frequency Aperture Array, etc.), exchanging commands and data with each of them. TM in turn needs to be monitored and controlled, in order its continuous and proper operation – and therefore that of the whole SKA Telescope – is ensured. It appears indeed that, while the unavailability of one or more instances of any other SKA element should result only in a degraded operation for the whole telescope, a problem in TM could cause a complete stop of any operation. In addition to this higher responsibility, a local monitoring and control system for TM has to collect and display logging data directly to operators, perform lifecycle management of TM applications and directly deal - when possible - with management of TM faults (which also includes a direct handling of TM status and performance data). In this paper, the peculiarities presented by the TM monitoring and control and the consequences they have on the design of a related LMC system are addressed and discussed.
Access to the requested content is limited to institutions that have purchased or subscribe to SPIE eBooks.
You are receiving this notice because your organization may not have SPIE eBooks access.*
*Shibboleth/Open Athens users─please
sign in
to access your institution's subscriptions.
To obtain this item, you may purchase the complete book in print or electronic format on
SPIE.org.
INSTITUTIONAL Select your institution to access the SPIE Digital Library.
PERSONAL Sign in with your SPIE account to access your personal subscriptions or to use specific features such as save to my library, sign up for alerts, save searches, etc.