Easylife: the data reduction and survey handling system for VIPERS

We present Easylife, the software environment developed within the framework of the VIPERS project for automatic data reduction and survey handling. Easylife is a comprehensive system to automatically reduce spectroscopic data, to monitor the survey advancement at all stages, to distribute data within the collaboration and to release data to the whole community. It is based on the OPTICON founded project FASE, and inherits the FASE capabilities of modularity and scalability. After describing the software architecture, the main reduction and quality control features and the main services made available, we show its performance in terms of reliability of results. We also show how it can be ported to other projects having different characteristics.Comment: pre-print, 17 pages, 4 figures, accepted for publication in Publications of the Astronomical Society of the Pacifi

Towards evaluation design for smart city development

Smart city developments integrate digital, human, and physical systems in the built environment. With growing urbanization and widespread developments, identifying suitable evaluation methodologies is important. Case-study research across five UK cities - Birmingham, Bristol, Manchester, Milton Keynes and Peterborough - revealed that city evaluation approaches were principally project-focused with city-level evaluation plans at early stages. Key challenges centred on selecting suitable evaluation methodologies to evidence urban value and outcomes, addressing city authority requirements. Recommendations for evaluation design draw on urban studies and measurement frameworks, capitalizing on big data opportunities and developing appropriate, valid, credible integrative approaches across projects, programmes and city-level developments

Monitoring System for Storm Readiness and Recovery of Test Facilities: Integrated System Health Management (ISHM) Approach

Severe weather events are likely occurrences on the Mississippi Gulf Coast. It is important to rapidly diagnose and mitigate the effects of storms on Stennis Space Center's rocket engine test complex to avoid delays to critical test article programs, reduce costs, and maintain safety. An Integrated Systems Health Management (ISHM) approach and technologies are employed to integrate environmental (weather) monitoring, structural modeling, and the suite of available facility instrumentation to provide information for readiness before storms, rapid initial damage assessment to guide mitigation planning, and then support on-going assurance as repairs are effected and finally support recertification. The system is denominated Katrina Storm Monitoring System (KStorMS). Integrated Systems Health Management (ISHM) describes a comprehensive set of capabilities that provide insight into the behavior the health of a system. Knowing the status of a system allows decision makers to effectively plan and execute their mission. For example, early insight into component degradation and impending failures provides more time to develop work around strategies and more effectively plan for maintenance. Failures of system elements generally occur over time. Information extracted from sensor data, combined with system-wide knowledge bases and methods for information extraction and fusion, inference, and decision making, can be used to detect incipient failures. If failures do occur, it is critical to detect and isolate them, and suggest an appropriate course of action. ISHM enables determining the condition (health) of every element in a complex system-of-systems or SoS (detect anomalies, diagnose causes, predict future anomalies), and provide data, information, and knowledge (DIaK) to control systems for safe and effective operation. ISHM capability is achieved by using a wide range of technologies that enable anomaly detection, diagnostics, prognostics, and advise for control: (1) anomaly detection algorithms and strategies, (2) fusion of DIaK for anomaly detection (model-based, numerical, statistical, empirical, expert-based, qualitative, etc.), (3) diagnostics/prognostics strategies and methods, (4) user interface, (5) advanced control strategies, (6) integration architectures/frameworks, (7) embedding of intelligence. Many of these technologies are mature, and they are being used in the KStorMS. The paper will describe the design, implementation, and operation of the KStorMS; and discuss further evolution to support other needs such as condition-based maintenance (CBM)

2020 NASA Technology Taxonomy

This document is an update (new photos used) of the PDF version of the 2020 NASA Technology Taxonomy that will be available to download on the OCT Public Website. The updated 2020 NASA Technology Taxonomy, or "technology dictionary", uses a technology discipline based approach that realigns like-technologies independent of their application within the NASA mission portfolio. This tool is meant to serve as a common technology discipline-based communication tool across the agency and with its partners in other government agencies, academia, industry, and across the world

DALiuGE: A Graph Execution Framework for Harnessing the Astronomical Data Deluge

The Data Activated Liu Graph Engine - DALiuGE - is an execution framework for processing large astronomical datasets at a scale required by the Square Kilometre Array Phase 1 (SKA1). It includes an interface for expressing complex data reduction pipelines consisting of both data sets and algorithmic components and an implementation run-time to execute such pipelines on distributed resources. By mapping the logical view of a pipeline to its physical realisation, DALiuGE separates the concerns of multiple stakeholders, allowing them to collectively optimise large-scale data processing solutions in a coherent manner. The execution in DALiuGE is data-activated, where each individual data item autonomously triggers the processing on itself. Such decentralisation also makes the execution framework very scalable and flexible, supporting pipeline sizes ranging from less than ten tasks running on a laptop to tens of millions of concurrent tasks on the second fastest supercomputer in the world. DALiuGE has been used in production for reducing interferometry data sets from the Karl E. Jansky Very Large Array and the Mingantu Ultrawide Spectral Radioheliograph; and is being developed as the execution framework prototype for the Science Data Processor (SDP) consortium of the Square Kilometre Array (SKA) telescope. This paper presents a technical overview of DALiuGE and discusses case studies from the CHILES and MUSER projects that use DALiuGE to execute production pipelines. In a companion paper, we provide in-depth analysis of DALiuGE's scalability to very large numbers of tasks on two supercomputing facilities.Comment: 31 pages, 12 figures, currently under review by Astronomy and Computin

Developing an architecture for a test sequencer

Testing is an important aspect of developing systems and products. It ensures quality of the product and that it works as it has been specified to work. Testing is a very expensive and time consuming process. It can be made more effective by automating it using test automation tools. In this work a test automation tool called DriveTest2 is developed. DriveTest2 is a test sequencer that can be used to test different kinds of devices. A test sequencer is a program that controls a test setup by creating command sequences to device under test and other devices in the test setup. DriveTest2 will be capable of data acquisition during tests. This data is used for monitoring the sequence and for test reports. DriveTest2 can be used for different kinds of testing such as verification, reliability, accelerated lifetime and stress testing. DriveTest2 will replace an existing software called DriveTest. DriveTest is replaced because it is hard to maintain and update, and there is no documentation. The objective of this work is to find out what kind of software archi tecture a test sequencer should have. DriveTest2 and its architecture is developed using an iterative development process. Develop ment starts from gathering and analyzing requirements for the software which was done in pre vious work. The first iteration of the architecture is created from these requirements. Then the first design and implementation of DriveTest2 is created and given to users to get feedback. According to the feedback and requirements, refinements to the architecture and implementa tion are made. Then this process is repeated until we have software that we are satisfied with. DriveTest2 is developed using C# programming language. DriveTest2 uses Model-View-View Model architectural pattern to separate user interface and business logic. The business logic of DriveTest2 is designed to be object-oriented and is modelled using UML class diagrams. Throughout the iterations the architecture and design are refined with changes to the initial architecture and new functionalities like new interfaces to handle device specific functionalities. As a result of this work, we have an iteration of DriveTest2 that is used in test laboratories with success. The software architecture of DriveTest2 enables DriveTest2 to satisfies its critical func tional and non-functional requirements. We can conclude that a test sequencer software archi tecture should be able to enable the software to satisfy its requirements, have decoupled com ponents with clear responsibilities, be flexible enough to accommodate changes to the architec ture during the development and be extensible so that new functionalities can be added and make use of abstraction to abstract lower-level components and the actual hardware.Testaaminen on tärkeä osa tuotteiden ja systeemien kehityksessä. Sillä varmistetaan, että tuote pystyy tekemään sille määritetyt asiat ja, että se on laadukas. Testaaminen on hyvin kallis ja aikaa vievä prosessi. Sitä voidaan tehostaa automatisoimalla käyttäen testiautomaa-tiotyökaluja. Tässä työssä kehitetään testiautomaatiotyökalu nimeltä DriveTest2. DriveTest2 on testisekvensseri, jota voidaan käyttää erilaisten laitteiden testaamiseen. Testisekvenssi on ohjelma, jolla voidaan ohjata testiympäristön laitteita luomalla sekvenssejä, jotka muo-dostuvat komennoista. DriveTest2 pystyy keräämään dataa sekvenssin ajon aikana. Tätä da-taa käytetään sekvenssin ajon monitorointiin ja testiraportissa. DriveTest2:sta voidaan käyt-tää erilaisissa testeissä kuten verifikaatio-, luotettavuus-, elinikä- ja stressitesteissä. Drive-Test2 korvaa olemassa olevan testisekvensserin nimeltä DriveTest. DriveTest korvataan, kos-ka sitä on vaikea ylläpitää ja päivittää ja siihen ei ole olemassa dokumentaatiota. Tämän työn tavoite on selvittää millainen ohjelmistoarkkitehtuuri testisekvensseri pitää olla. DriveTest2 ja sen ohjelmistoarkkitehtuuria kehitetään iteratiivisella kehitysprosessilla. Kehi-tys alkaa vaatimusten keräämisellä ja analysoinnilla, joka tehtiin aikaisemmassa työssä. Näi-den vaatimusten perusteella luodaan ensimmäinen versio ohjelmistoarkkitehtuurista. Tämän ohjelmistoarkkitehtuurin perusteella luodaan ensimmäinen iteraatio DriveTest2:sen toteu-tuksesta ja se annetaan käyttäjille saadaksemme palautetta. Palautteen ja vaatimusten pe-rusteella arkkitehtuuria ja toteutusta hiotaan paremmaksi. Tätä prosessia sitten toistetaan, kunnes todetaan, että ohjelmisto on riittävän hyvä. DriveTest2 kehitetään C# ohjelmointikielellä. DriveTest2 käyttää Model-View-ViewModel arkkitehtuurimallia erottaakseen käyttöliittymän muusta logiikasta. DriveTest2:sen logiikka on tehty olio-ohjelmoinnilla ja se on mallinnettu UML luokkakaavioilla. Iteraatioiden aikana Dri-veTest2:sen ohjelmistoarkkitehtuuria hiottiin paremmaksi muuttamalla aikaisempaa arkki-tehtuuria ja lisäämällä uusia toiminnallisuuksia kuten uusia rajapintoja hoitamaan laitekohtai-sia toiminallisuuksia. Työn tuloksena saatiin luotua iteraatio DriveTest2:sta, jota pystytään käyttämään testilabora-torioissa hyvällä menestyksellä. DriveTest2:sen ohjelmistoarkkitehtuuri pystyy mahdollista-maan, että DriveTest2 pystyy toteuttamaan sille määritetyt toiminnalliset ja ei-toiminnalliset vaatimukset. Voidaan päätellä, että testisekvensserin ohjelmistoarkkitehtuurin on pystyttävä mahdollistamaan sille määritettyjen vaatimusten täyttäminen. Sillä on oltava komponentejä, joilla on selvät vastuualueet, ja sen on hyödynnettävä abstraktointia varsinkin laitetasolla. Arkkitehtuurin on oltava joustava, jotta sitä voidaan muokata ja kehittää kehityksen aikana sekä lisäämään uusia toiminnallisuuksia