This paper presents the specification, design, and development of the Visible Camera (VIS) on the ESA Euclid mission. VIS is a large optical-band imager with a field of view of 0.54 deg^2 sampled at 0.1" with an array of 609 Megapixels and spatial resolution of 0.18". It will be used to survey approximately 14,000 deg^2 of extragalactic sky to measure the distortion of galaxies in the redshift range z=0.1-1.5 resulting from weak gravitational lensing, one of the two principal cosmology probes of Euclid. With photometric redshifts, the distribution of dark matter can be mapped in three dimensions, and, from how this has changed with look-back time, the nature of dark energy and theories of gravity can be constrained. The entire VIS focal plane will be transmitted to provide the largest images of the Universe from space to date, reaching m_AB>24.5 with S/N >10 in a single broad I_E~(r+i+z) band over a six year survey. The particularly challenging aspects of the instrument are the control and calibration of observational biases, which lead to stringent performance requirements and calibration regimes. With its combination of spatial resolution, calibration knowledge, depth, and area covering most of the extra-Galactic sky, VIS will also provide a legacy data set for many other fields. This paper discusses the rationale behind the VIS concept and describes the instrument design and development before reporting the pre-launch performance derived from ground calibrations and brief results from the in-orbit commissioning. VIS should reach fainter than m_AB=25 with S/N>10 for galaxies of full-width half-maximum of 0.3" in a 1.3" diameter aperture over the Wide Survey, and m_AB>26.4 for a Deep Survey that will cover more than 50 deg^2. The paper also describes how VIS works with the other Euclid components of survey, telescope, and science data processing to extract the cosmological information.

ARIEL (Atmospheric Remote-sensing InfraRed Large-survey) is a medium-class mission of the European Space Agency, part of the Cosmic Vision program, whose launch is foreseen by early 2029. ARIEL aims to study the composition of exoplanet atmospheres, their formation and evolution. The ARIEL’s target will be a sample of about 1000 planets observed with one or more of the following methods: transit, eclipse and phase-curve spectroscopy, at both visible and infrared wavelengths simultaneously. The scientific payload is composed by a reflective telescope having a 1m-class elliptical primary mirror, built in solid Aluminium, and two focal-plane instruments: FGS and AIRS. FGS (Fine Guidance System)1 has the double purpose, as suggested by its name, of performing photometry (0.50-0.55 μm) and low resolution spectrometry over three bands (from 0.8 to 1.95 µm) and, simultaneously, to provide data to the spacecraft AOCS (Attitude and Orbit Control System) with a cadence of 10 Hz and contributing to reach a 0.02 arcsec pointing accuracy for bright targets. AIRS (ARIEL InfraRed Spectrometer) instrument will perform IR spectrometry in two wavelength ranges: between 1.95 and 3.9 μm (with a spectral resolution R < 100) and between 3.9 and 7.8 μm with a spectral resolution R < 30. This paper provides the status of the ICU (Instrument Control Unit), an electronic box whose purpose is to command and supply power to AIRS (as well as acquire science data from its two channels) and to command and control the TCU (Telescope Control Unit).

The ARIEL Instrument Control Unit (ICU) implements the monitoring, control, and commanding of both the ARIEL IR Spectrometer (AIRS) and Telescope Control Unit (TCU). It acquires the AIRS scientific data provided by the AIRS detector control units and implements the onboard pre-processing and downlink to the satellite Mass Memory. Based on a preliminary Technical Specification, a high-level preliminary software architecture has been produced. In this paper we provide the ARIEL ICU Application SW layers description and some examples of the static and dynamic diagrams that will be included in the final architecture

PLATO (PLAnetary Transits and Oscillations of stars) is the third medium-class mission (M3), selected by the European Space Agency (ESA) in 2014 and adopted in 2017 for the Cosmic Vision 2015-2025 scientific program. The launch is scheduled in 2026 from the French Guiana (Kourou) for a nominal in-orbit lifetime of 4 years plus up to 4 years of possible extension. The main purpose of the mission is the discovery and preliminary characterization of many different types of exoplanets down to rocky terrestrial planets orbiting around bright solar-type stars. The PLATO spacecraft will operate from a halo orbit around L2 (the Sun-Earth 2nd Lagrangian Point), a virtual point in space, 1.5 million km beyond Earth as seen from the Sun and its Payload will consist of 26 small telescopes (24 normal and 2 fast), pointing at the same target stars, that provide images every 25 seconds with the normal camera and every 2.5 seconds for the two fast cameras, operating in a close loop with the AOCS (S/C Attitude and Orbit Control System). Each camera (consisting of a telescope, the Focal Plane Assembly and its Front-End Electronics) will host four CCDs producing 20.3 megapixels images adding up to 81.4 megapixels per normal camera and 2.11 gigapixels for the overall Payload (P/L). This huge amount of data cannot be transmitted to the ground and need to be processed on-board by the P/L Data Processing System (DPS) made up of various processing electronic units. The DPS of the PLATO instrument comprises the Normal and Fast DPUs (Data Processing Units) and a single ICU (Instrument Control Unit), in charge of HW and SW lossless data compression and managing the P/L through a SpaceWire (SpW) network. In this paper we will review the status of the Instrument Control Unit (ICU) after its Critical Design Review (CDR) process, performed by ESA and PMC (PLATO Mission Consortium), the results of the performance test preliminary run on the Engineering Model (EM), waiting for the following Engineering and Qualification Model (EQM) and Proto-Flight Model (PFM), and the status of the early models development (Engineering Models 1 and 2, Mass and Thermal Dummy - MTD) that, along with the Boot SW (BSW) burning in PROM readiness, will enable the EQM manufacturing.

PLAnetary Transits and Oscillations of stars (PLATO) is a medium-class mission selected by ESA in the framework of the Cosmic Vision programme. The PLATO Instrument Control ICU is responsible for the management of the scientific payload, the communication with the SVM, and the lossless compression of scientific data before the download to the satellite Mass memory. The ICU requirements have been finalized for the Preliminary Design Review. The resulting technical specification has been used to design a Model Based Software architecture. The first two versions of the PLATO ICU SW have been released and fully validated on the target platform. This paper provides the details of the solutions adopted to cover all implemented services.

The PLAnetary Transits and Oscillations of stars (PLATO) is a space telescope under ESA development. The (PLATO’s) Instrument Control Unit (ICU) is an electronics box that is responsible for the management (MGT) of the payload (P/L), the communication with the Service Module (SVM), and the compression of scientific data before transmitting them as telemetries TMs to the SVM. The ICU receives data from 2 “fast” (F-DPU) each 2.5s and 24 normal Data Processing Units (N-DPU) each 25s. In order to reduce the huge data volume produced on-board by the 104 CCD (4 CCD per camera), for each target star it will be allocated a window, from which all the pixel values will be gathered, forming a small image called “imagette”. These cropped images are compressed by means of a lossless algorithm running in the ICU FPGA and transmitted as Packet Utilization Standard (PUS) packets to SVM. These streamlined transmissions require qualified compression and decompression techniques to preserve images. In this poster we propose a scripting tool that classifies and collects automatically telemetry PUS packets, hosting scientific data and metadata, to reconstruct compressed imagettes on-ground.

Ariel, the Atmospheric Remote-sensing Infrared Exoplanet Large-survey mission (Tinetti 2019; Puig et al. 2018; Pascale et al. 2018), has been selected in March 2018 by ESA for the fourth medium-class mission (M4) launch opportunity of the Cosmic Vision Program, with an expected lift off in late 2028. It is the first mission dedicated to measuring the chemical composition and thermal structures of the atmospheres of hundreds of transiting exoplanets, enabling planetary science far beyond the boundaries of our own Solar System. Its Payload (P/L) (Eccleston and Tinetti 2018; Eccleston et al. 2017; Middleton et al. 2019), has been designed to perform transit spectroscopy from space during primary and secondary planetary eclipses in order to achieve a large unbiased survey concerning the nature of exoplanets atmospheres and their interiors, to determine the key factors affecting the formation and evolution of planetary systems (Tinetti et al. 2017, 2018). Ariel will observe hundreds of warm and hot transiting gas giants, Neptunes and super-Earths around a wide range of host star types, targeting planets hotter than $\sim $ 600 K to take advantage of their well-mixed atmospheres. It will exploit primary and secondary transit spectroscopy in the 1.10 to 7.80 μm spectral range and broad-band photometry in the optical (0.50 - 0.80 μm) and Near IR (0.80 - 1.10 μm) . One of the two instruments of the Ariel Payload is the Fine Guidance System (FGS), including three photometric channels (two used for guiding as well as science) between 0.5-1.1 μm plus a low resolution NIR spectrometer for 1.1-1.95 μm range. Along with FGS an IR Spectrometer (AIRS) (Amiaux et al. 2017) is foreseen, 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. Finally, an Active Cooler System (ACS) including a Ne Joule-Thomson cooler is adopted to provide active cooling capability to the AIRS detectors working at cryogenic temperatures. AIRS is located at the intermediate focal plane of the telescope and common optical system and it hosts two HgCdTe-based hybrid IR detectors and two cold front-end electronics (CFEE) for detectors control and readout. Each CFEE is driven by a Detector Control Unit (DCU) part of AIRS but hosted within and managed by the Instrument Control Unit (ICU) of the Payload (Focardi et al. 2018). ICU is a warm unit residing into the S/C Service Module (SVM) and it is based on a cold redundant configuration involving the Power Supply Unit (PSU) and the Commanding and Data Processing Unit (CDPU) boards; both DCUs are instead cross-strapped and can be managed by the nominal or the redundant (PSU+CDPU) chain. ICU is in charge of AIRS management, collecting scientific and housekeeping (HK) telemetries from the spectrometer and HK from the telescope (temperatures readings), the P/L Optical Bench (OB) and other Subsystems (SS), thanks to a warm slave unit (TCU, Telescope Control Unit) interfaced to the ICU. Science and HK telemetries are then forwarded to the S/C, for temporary storage, before sending them to Ground. Here we describe the status of the ICU design at the end of B1 Phase, prior to the Mission Adoption Review (MAR) by ESA, with some still open architectural choices to be addressed and finalised once selected the ICU industrial Prime contractor.

PLATO is an M-class mission (M3) of the European Space Agency (ESA) whose launch is scheduled in 2026. The main aim of the mission is the detection and characterization of terrestrial exoplanets orbiting around bright solar-type star. The payload consists of 26 small telescopes: 24 “normal" cameras and 2 “fast" cameras. The huge amount of data produced by the PLATO telescopes is acquired and processed on-board by the Data Processing System (DPS) made up by various processing electronic units. The DPS of the PLATO instrument comprises the Normal and Fast DPUs (Data Processing Units) and a single ICU (Instrument Control Unit), are data routed through a SpaceWire network. The topic of this paper is the description of the architecture of the ICU and its role within the DPS, the status of the Avionic Validation Model (AVM) testing at the end of the Unit Preliminary Design Review (UPDR) performed by ESA and the results of the test of the first engineering model.

PLAnetary Transits and Oscillations of stars (PLATO) is a mission belonging to the European Space Agency Cosmic Vision program which objective is to find and study extrasolar planetary systems. PLATO is composed of 26 telescopes which will observe uninterruptedly Sun like stars in order to identify a periodic decrease of the star brightness indicating the possible transit of an exoplanet. The PLATO on-board Data Processing System (DPS) consists of an Instrument Control Unit (ICU) and several distributed Digital Processing Units (DPUs) connected together by a SpaceWire network. The ICU collects and compresses scientific data from the DPUs and it implements the main data interface towards the satellite for telemetry and telecommands. The focus of this paper is on the Boot Software (BSW) of the ICU. The BSW is executed on a LEON3FT processor to perform system initialization, hardware checks, telecommand/telemetry management and the start of the ICU Application Software (ASW) responsible of the PLATO sub-system management necessary for the mission objectives. ICU BSW is the only boot software on-board PLATO and its high criticality level requires stringent verification/validation activities and a high-quality control of the software product which is achieved through extensive quality plans, multi-level testing and static analysis of software code. This paper describes the BSW dependable architecture along with the methods used to achieve the required performances, including FDIR techniques. Two engineering models of the ICU are going to be developed and the foreseen functional and performance tests will be presented in this paper.

ARIEL, the Atmospheric Remote-sensing Infrared Exoplanet Large-survey mission1-3 was selected in early 2018 by the European Space Agency (ESA) as the fourth medium-class mission (M4) launch opportunity of the Cosmic Vision Program, with an expected launch in late 2028. It is the first mission dedicated to the analysis of the chemical composition and thermal structures of up to a thousand transiting exoplanets atmospheres, which will expand planetary science far beyond the limits of our current knowledge.

In this paper we describe the activities towards the design of a common framework for the Instrument Control and Data Processing Units for the three scientific payload instruments on board the joint ESA-JAXA SPICA mission, currently at the end of its phase A study. In this context, we started a program to assess modular architectures based on the use of a quad-core fault-tolerant LEON4 SPARC V8 processor on a SpaceWire network. We will describe the results of our initial tests using both Asymmetric Multi processing (AMP) and Symmetric Multi Processing (SMP) configurations. In addition, the possibility to adopt the RTEMS real time operating system, already space qualified on single core processors, will be evaluated both in terms of latency performances and of dynamical allocation of the resources. Finally, we will present the outline of the way forward for the next phases of the SPICA project.

Euclid-VIS is a large format visible imager for the ESA Euclid space mission in their Cosmic Vision program, scheduled for launch in 2019. Together with the near infrared imaging within the NISP instrument it forms the basis of the weak lensing measurements of Euclid. VIS will image in a single r+i+z band from 550-900 nm over a field of view of 0.5 deg2. By combining 4 exposures with a total of 2240 sec, VIS will reach to V=24.5 (10σ) for sources with extent 0.3 arcsec. The image sampling is 0.1 arcsec. VIS will provide deep imaging with a tightly controlled and stable point spread function (PSF) over a wide survey area of 15000 deg2 to measure the cosmic shear from nearly 1.5 billion galaxies to high levels of accuracy, from which the cosmological parameters will be measured. In addition, VIS will also provide a legacy imaging dataset with an unprecedented combination of spatial resolution, depth and area covering most of the extra-Galactic sky. Here we will present the results of the study carried out by the Euclid Consortium during the Euclid Definition phase.

INAF IAPS research groups have a long time expertise in the production of scientific instrumentation for space missions. Thanks to ASI funding and in collaboration with the national industries leader in the space sector, IAPS, the Institute for Space Astrophisics and Planetology of INAF, often participates in the development of control electronics for space instrumentation. Over the years, the need to use FPGAs for the implementation of some of the instrument control functionalities (microcontrollers, interfaces, algorithms data processing) has increased, thanks to their small size and weight, very low power consumption, radiation tolerance and high reliability. This contribution provides a brief description of some examples of IAPS developed systems, highlighting what may be the potential need for future collaborations.

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.

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.

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.

SAFARI (SpicA FAR infrared Instrument) is a far-infrared imaging Fourier Transform Spectrometer for the SPICA mission. The Digital Processing Unit (DPU) of the instrument implements the functions of controlling the overall instrument and implementing the science data compression and packing. The DPU design is based on the use of a LEON family processor. In SAFARI, all instrument components are connected to the central DPU via SpaceWire links. On these links science data, housekeeping and commands flows are in some cases multiplexed, therefore the interface control shall be able to cope with variable throughput needs. The effective data transfer workload can be an issue for the overall system performances and becomes a critical parameter for the on-board software design, both at application layer level and at lower, and more HW related, levels. To analyze the system behavior in presence of the expected SAFARI demanding science data flow, we carried out a series of performance tests using the standard GR-CPCI-UT699 LEON3-FT Development Board, provided by Aeroflex/Gaisler, connected to the emulator of the SAFARI science data links, in a point-to-point topology. Two different communication protocols have been used in the tests, the ECSS-E-ST-50-52C RMAP protocol and an internally defined one, the SAFARI internal data handling protocol. An incremental approach has been adopted to measure the system performances at different levels of the communication protocol complexity. In all cases the performance has been evaluated by measuring the CPU workload and the bus latencies. The tests have been executed initially in a custom low level execution environment and finally using the Real- Time Executive for Multiprocessor Systems (RTEMS), which has been selected as the operating system to be used onboard SAFARI. The preliminary results of the carried out performance analysis confirmed the possibility of using a LEON3 CPU processor in the SAFARI DPU, but pointed out, in agreement with previous similar studies, the need of carefully designing the overall architecture to implement some of the DPU functionalities on additional processing devices.

Euclid is a space mission dedicated to the high-precision study of dark energy and dark matter. Its visible instrument (VIS) will acquire wide field images by means of an array of 36 CCD focal plane detectors. Considering that each acquired full frame produces a huge amount of data (~1.2GByte), an overall daily production of ~120 GByte is expected, which must be compressed to fit the 520 Gbit VIS daily telemetry. Due to the highly demanding science requirements such compression must be rigorously lossless. This software requirement is very hard to meet because of the following constraints: i) the average Compression Ratio (CR) must be greater than 2.8; ii) the activities of data compression inside the Control Data Processing Unit and transmission towards the satellite shall complete in less than 369s, that fits to the acquisition time of the near-infrared instrument; and iii) the compressors parameters as well as the transmission packet size must be tuned to ensure minimal data loss in case of transmission errors. The results obtained with 1D and 2D compression algorithms based on the CCSDS 121 and CCSDS 122 recommended standards, fed with improved focal plane simulations, have been compared to each other. Moreover, a set of various reordering and pre-processing procedures has been applied to the read-out data stream, considering different sizes of the input data segments. The overall scope of these comparative works has been not only to maximize the compression ratio and to minimize the compression time, but also to provide a trade-off between the input data size and the minimum output compressed data segment in order to minimize the data loss due to transmission errors propagation. From our test we found that performing a full (at CCD level) reordering of the read-out data-stream leads to a better compression ratio with both algorithms. The CCSDS 121, however, gives the best results in terms of CR. Finally we found that, for the considered simulated images, the standard pre-processing activities like bias subtraction, bitshift and windowing do not affect the CR significantly. Analogously an additional analysis of the effect of the expected source crowding showed that it is also not important.

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.