PROCEEDINGS ARTICLE | July 18, 2014
Proc. SPIE. 9152, Software and Cyberinfrastructure for Astronomy III
KEYWORDS: Safety, Aerospace engineering, Satellites, Interfaces, Control systems, Data processing, Software development, Charge-coupled devices, Space operations, Systems modeling
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.
