M. Farina

The ARIEL Instrument Control Unit design: For the M4 Mission Selection Review of the ESA’s Cosmic Vision Program

The Atmospheric Remote-sensing Infrared Exoplanet Large-survey mission (ARIEL) (Tinetti et al. 2017) is one of the three present candidates for the ESA M4 (the fourth medium mission) launch opportunity. The proposed Payload (Eccleston et al. 2017; Morgante et al. 2017; Da Deppo et al. 2017) will perform a large unbiased spectroscopic survey from space concerning the nature of exoplanets atmospheres and their interiors to determine the key factors affecting the formation and evolution of planetary systems. ARIEL will observe a large number (> 500) of warm and hot transiting gas giants, Neptunes and super-Earths around a wide range of host star types, targeting planets hotter than 600 K to take advantage of their well-mixed atmospheres. It will exploit primary and secondary transits spectroscopy in the 1.2 − 8μm spectral range and broad-band photometry in the optical and Near IR (NIR). The main instrument of the ARIEL Payload is the IR Spectrometer (AIRS) (Amiaux et al. 2017) providing low-resolution spectroscopy in two IR channels: Channel 0 (CH0) for the 1.95 − 3.90μm band and Channel 1 (CH1) for the 3.90 − 7.80μm range. It is located at the intermediate focal plane of the telescope (Da Deppo et al. 2016, 2017, 2017) and common optical system and it hosts two IR sensors and two cold front-end electronics (CFEE) for detectors readout, a well defined process calibrated for the selected target brightness and driven by the Payload’s Instrument Control Unit (ICU).

The Atmospheric Remote-sensing Infrared Exoplanets Large-survey (ARIEL) payload electronic subsystems

The ARIEL mission has been proposed to ESA by an European Consortium as the first space mission to extensively perform remote sensing on the atmospheres of a well defined set of warm and hot transiting gas giant exoplanets, whose temperature range between ~600 K and 3000 K. ARIEL will observe a large number (~500) of warm and hot transiting gas giants, Neptunes and super-Earths around a range of host star types using transit spectroscopy in the ~2-8 μm spectral range and broad-band photometry in the NIR and optical. ARIEL will target planets hotter than 600 K to take advantage of their well-mixed atmospheres, which should show minimal condensation and sequestration of high-Z materials and thus reveal their bulk and elemental composition. One of the major motivations for exoplanet characterisation is to understand the probability of occurrence of habitable worlds, i.e. suitable for surface liquid water. While ARIEL will not study habitable planets, its major contribution to this topic will results from its capability to detect the presence of atmospheres on many terrestrial planets outside the habitable zone and, in many cases, characterise them. This represents a fundamental breakthrough in understanding the physical and chemical processes of a large sample of exoplanets atmospheres as well as their bulk properties and to probe in-space technology. The ARIEL infrared spectrometer (AIRS) provides data on the atmospheric composition; these data are acquired and processed by an On-Board Data Handling (OBDH) system including the Cold Front End Electronics (CFEE) and the Instrument Control Unit (ICU). The Telescope Control Unit (TCU) is also included inside the ICU. The latter is directly connected to the Control and Data Management Unit (CDMU) on board the Service Module (SVM). The general hardware architecture and the application software of the ICU are described. The Fine Guidance Sensor (FGS) electronics and the Cooler Control Electronics are also presented.

EChO payload electronics architecture and SW design

EChO is a three-modules (VNIR, SWIR, MWIR), highly integrated spectrometer, covering the wavelength range from 0.55 μm to 11.0 μm. The baseline design includes the goal wavelength extension to 0.4 μm while an optional LWIR module extends the range to the goal wavelength of 16.0 μm. An Instrument Control Unit (ICU) is foreseen as the main electronic subsystem interfacing the spacecraft and collecting data from all the payload spectrometers modules. ICU is in charge of two main tasks: the overall payload control (Instrument Control Function) and the housekeepings and scientific data digital processing (Data Processing Function), including the lossless compression prior to store the science data to the Solid State Mass Memory of the Spacecraft. These two main tasks are accomplished thanks to the Payload On Board Software (P-OBSW) running on the ICU CPUs.

An improved version of the Visible and Near Infrared (VNIR) spectrometer of EChO

The Visible and Near Infrared (VNIR) is one of the modules of EChO, the Exoplanets Characterization Observatory proposed to ESA for an M-class mission. EChO is aimed to observe planets while transiting by their suns. Then the instrument has be designed to assure a high efficiency over the whole spectral range. In fact, it has to be able to observe stars with an apparent magnitude Mv= 9÷12 and able to see contrasts of 10-4÷10-5 in order to reveal the characteristics of the atmospheres of the exoplanets under investigation. VNIR was originally designed for covering the spectral range from 0.4 to 1.0 μm [1] but now the design has been reviewed and its spectral range has been extended up to 2.5 μm. It is a spectrometer in a cross-dispersed configuration that, then, uses the combination of a diffraction grating and a prism to spread the light in different wavelengths and in a useful number of orders of diffraction. Its resolving power is about 330 over the entire spectral range and its field of view is approximately 2 arcsec. The spectrometer is functionally split into two channels respectively working in the 0.4-1.0 μm and 1.0-2.5 μm spectral ranges. Such a solution is imposed by the fact the light at low wavelengths has to be shared with the EChO Fine Guiding System (FGS) devoted to the pointing of the stars under observation. The instrument works at 45K and its weight is 6 kg.

Preliminary study of the EChO data sampling and processing

The EChO Payload is an integrated spectrometer with six different channels covering the spectral range from the visible up to the thermal infrared. A common Instrument Control Unit (ICU) implements all the instrument control and health monitoring functionalities as well as all the onboard science data processing. To implement an efficient design of the ICU on board software, separate analysis of the unit requirements are needed for the commanding and housekeeping collection as well as for the data acquisition, sampling and compression. In this work we present the results of the analysis carried out to optimize the EChO data acquisition and processing chain. The HgCdTe detectors used for EChO mission allow for non-destructive readout modes, such that the charge may be read without removing it after reading out. These modes can reduce the equivalent readout noise and the gain in signal to noise ratio can be computed using well known relations based on fundamental principles. In particular, we considered a multiaccumulation approach based on non-destructive reading of detector samples taken at equal time intervals. All detectors are periodically reset after a certain number of samples have been acquired and the length of the reset interval, as well as the number of samples and the sampling rate can be adapted to the brightness of the considered source. The estimation of the best set of parameters for the signal to noise ratio optimization and of the best sampling technique has been done by taking into account also the needs of mitigating the expected radiation effects on the acquired data. Cosmic rays can indeed be one of the major sources of data loss for a space observatory, and the studies made for the JWST mission allowed us to evaluate the actual need of the implementation of a dedicated deglitching procedure on board EChO.

The instrument control unit of the EChO space mission: electrical architecture and processing requirements

The Exoplanet Characterization Observatory (EChO) is conceived for the spectrophotometric study from space of the atmospheres of a selected target sample of transiting extra-solar planets. It has been designed to run as a candidate for the M3 launch opportunity of the ESA Cosmic Vision program and can be considered as the next step towards the fully characterization of a representative sample of the already discovered transiting exoplanets. The EChO payload is based on a single highly thermo-mechanical stabilized remote-sensing instrument hosting a dispersive spectrograph. It is able to perform time-resolved spectroscopy exploiting the temporal and spectral variations of the measured signal due to the primary and secondary occultations occurring between the exoplanet and its parent star. The adopted technique allows the extraction of the planet spectral signature and to probe the physical and chemical properties of its atmosphere. EChO is composed by four scientific modules, all suited on a common Instrument Optical Bench (IOB). Each module is operated by a unique control and processing electronics, the Instrument Control Unit (ICU), acting as interface between the payload and the spacecraft (S/C) Data Management Subsystem (DMS) and Power Control and Distribution Unit (PCDU). The main ICU tasks concern the instrument commanding, based on the received and interpreted TC and TM; instrument monitoring and control by means of the housekeeping (HK) data acquired from the focal plane units; synchronization of all the scientific payload activities; detectors readout and data acquisition, pre-processing, lossless compression and formatting before downloading the TM science data and HK to the spacecraft mass memory. As far as the software is concerned, these activities can be basically grouped and managed by the Instrument Control software and Data Processing software; both will constitute the On Board Software of the overall payload designed to address all the processing requirements as driven by the EChO science case [1, 2]. This paper is conceived as a memory for an EChO-like payload electrical architecture with processing capabilities mainly driven by the scientific requirements as defined and frozen at the end of both the Payload Assessment Phase and the M3 mission selection process, held by ESA at the beginning of February 2014.

Design of the instrument and telescope control units integrated subsystem of the ESA-ARIEL payload

The Atmospheric Remote-sensing Infrared Exoplanets Large-survey (ARIEL)1 Mission has been recently selected by ESA as the fourth medium-class Mission (M4) in the framework of the Cosmic Vision Program. The goal of ARIEL is to investigate, thanks to VIS photometry and IR spectroscopy, the atmospheres of several hundreds of planets orbiting nearby stars in order to address the fundamental questions on how planetary systems form and evolve.2 During its four-years mission, ARIEL will observe several hundreds of exoplanets ranging from Jupiter- and Neptune-size down to super-Earth and Earth-size with its 1 meter-class telescope.3 The analysis of spectra and photometric data will allow to extract the chemical fingerprints of gases and condensates in the planets atmospheres, including the elemental composition for the most favorable targets. It will also enable the study of thermal and scattering properties of the atmosphere as the planet orbits around its parent star.

Performance analysis of the GR712RC dual-core LEON3FT SPARC V8 processor in an asymmetric multi-processing environment

In this paper we present the results of a series of performance tests carried out on a prototype board mounting the Cobham Gaisler GR712RC Dual Core LEON3FT processor. The aim was the characterization of the performances of the dual core processor when used for executing a highly demanding lossless compression task, acting on data segments continuously copied from the static memory to the processor RAM. The selection of the compression activity to evaluate the performances was driven by the possibility of a comparison with previously executed tests on the Cobham/Aeroflex Gaisler UT699 LEON3FT SPARC™ V8. The results of the test activity have shown a factor 1.6 of improvement with respect to the previous tests, which can easily be improved by adopting a faster onboard board clock, and provided indications on the best size of the data chunks to be used in the compression activity.

Software design for the VIS instrument onboard the Euclid mission: a multilayer approach

The Euclid mission scientific payload is composed of two instruments: a VISible Imaging Instrument (VIS) and a Near Infrared Spectrometer and Photometer instrument (NISP). Each instrument has its own control unit. The Instrument Command and Data Processing Unit (VI-CDPU) is the control unit of the VIS instrument. The VI-CDPU is connected directly to the spacecraft by means of a MIL-STD-1553B bus and to the satellite Mass Memory Unit via a SpaceWire link. All the internal interfaces are implemented via SpaceWire links and include 12 high speed lines for the data provided by the 36 focal plane CCDs readout electronics (ROEs) and one link to the Power and Mechanisms Control Unit (VI-PMCU). VI-CDPU is in charge of distributing commands to the instrument sub-systems, collecting their housekeeping parameters and monitoring their health status. Moreover, the unit has the task of acquiring, reordering, compressing and transferring the science data to the satellite Mass Memory. This last feature is probably the most challenging one for the VI-CDPU, since stringent constraints about the minimum lossless compression ratio, the maximum time for the compression execution and the maximum power consumption have to be satisfied. Therefore, an accurate performance analysis at hardware layer is necessary, which could delay too much the design and development of software. In order to mitigate this risk, in the multilayered design of software we decided to design a middleware layer that provides a set of APIs with the aim of hiding the implementation of the HW connected layer to the application one. The middleware is built on top of the Operating System layer (which includes the Real-Time OS that will be adopted) and the onboard Computer Hardware. The middleware itself has a multi-layer architecture composed of 4 layers: the Abstract RTOS Adapter Layer (AOSAL), the Speci_c RTOS Adapter Layer (SOSAL), the Common Patterns Layer (CPL), the Service Layer composed of two subgroups which are the Common Service (CSL) and the Specific Service layer (SSL). The middleware design is made using the UML 2.0 standard. The AOSAL includes the abstraction of services provided by a generic RTOS (e.g Thread/Task, Time Management, Mutex and Semaphores) as well as an abstraction of SpaceWire and 1553-B bus Interface. The SOSAL is the implementation of AOSAL for the adopted RTOS. The CPL provides a set of patterns that are a general solution for common problems related to embedded hard Real Time systems. This set includes patterns for memory management, homogenous redundancy channels, pipes and filters for data exchange, proxies for slow memories, watchdog and reactive objects. The CPL is designed using a soft-metamodeling approach, so as to be as general as possible. Finally, the SL provides a set of services that are common to space applications. The testing of this middleware can be done both during the design using appropriate tools of analysis and in the implementation phase by means of unit testing tools.

A traffic analyzer for multiple SpaceWire links

Modern space missions are becoming increasingly complex: the interconnection of the units in a satellite is now a network of terminals linked together through routers, where devices with different level of automation and intelligence share the same data-network. The traceability of the network transactions is performed mostly at terminal level through log analysis and hence it is difficult to verify in real time the reliability of the interconnections and the interchange protocols. To improve and ease the traffic analysis in a SpaceWire network we implemented a low-level link analyzer, with the specific goal to simplify the integration and test phases in the development of space instrumentation. The traffic analyzer collects signals coming from pod probes connected in-series on the interested links between two SpaceWire terminals. With respect to the standard traffic analyzers, the design of this new tool includes the possibility to internally reshape the LVDS signal. This improvement increases the robustness of the analyzer towards environmental noise effects and guarantees a deterministic delay on all analyzed signals. The analyzer core is implemented on a Xilinx FPGA, programmed to decode the bidirectional LVDS signals at Link and Network level. Successively, the core packetizes protocol characters in homogeneous sets of time ordered events. The analyzer provides time-tagging functionality for each characters set, with a precision down to the FPGA Clock, i.e. about 20nsec in the adopted HW environment. The use of a common time reference for each character stream allows synchronous performance measurements. The collected information is then routed to an external computer for quick analysis: this is done via high-speed USB2 connection. With this analyzer it is possible to verify the link performances in terms of induced delays in the transmitted signals. A case study focused on the analysis of the Time-Code synchronization in presence of a SpaceWire Router is shown in this paper as well.