State of the art data management and control in Satellite systems, depicted in Figure 1, is currently implemented on single processors with three levels software architecture: the Low Level Layer including a Board I/O System (BIOS) and real-time operating system (RTOS), a Data Handling Service Layer and an Application Layer. Applications running on the satellite central computer are typically the Attitude and Orbit Control system (AOCS), the housekeeping and management functions at satellite, platform and payload levels and the Data Management System. Failure Detection Isolation and Recovery mechanisms are also included in these applications. The global criticity level is homogeneous.

Figure 1 - Typical Satellite Central Software

With the increase of processing power and the push for reducing costs, weight, volume and power consumption, integrated and modular architectures have been introduced, inspired from the IMA implemented in Aircraft and AUTOSAR in Automotive domain, and powered by partitioned execution platform based on hypervisors. This enables the processing on a single computer of the Central software functions together with the more demanding data processing previously allocated to GNSS receivers and Star-trackers and previously implemented in separate additional computing devices. This led to the “very integrated avionics” as implemented in the ESA study “Prototyping a SpaceWire AOCS” illustrated by the Figure 2 below. This kind of architecture is today implemented in large constellation and could be also proposed for the next generation of Copernicus spacecraft provided more processing power becomes available in radiation hardened multicores.

Figure 2 - Very Integrated Central Software on the PSA study

In future systems, with more CPU performance available on board and more use of mainstream standards from other industrial and commercial domains, this approach could be taken for “new space” type of applications allowing use of commercial of the shelf parts (COTS), generally taken from the automotive or aeronautical domains. With such devices, the processing power becomes enough so as to take into account all required computing functions on a single device for many types of spacecraft, meaning including also the payload processing. Current high performance devices providing ARM multicores or future RISC V platforms are potentially carrying such opportunity. However, on such platform, the mixed criticality as well as the necessary dependability assurance shall be ensured.
For the SELENE project, the satellite use case aims at highlighting and demonstrating a number of objective and benefits such as:

  • Minimizing cost, weight, volume and power through electronics integration
  • Considerably simplify the payload data management design by the use of a common standard and generic execution platform with e.g. Linux available on-board 
  • Simplify S/W system integration thanks to incremental application validation 
  • Enable high criticality functions (e.g. manned flight, in-orbit rendez-vous, autonomous robotics operations, planetary landing) to share resources with less critical functions such as payload or vision base navigation image processing (illustrated in Figure 3).
Figure 3- Very High Performance SELENE integrated Software Architecture