Initial (and still active) objectives of KOSMOS

• Enable the reuse of recurring functions on space computers in the form of libraries or partitions.
• Simplify their integration and guarantee their independence thanks to the modularity offered by TSP/A653.
• Allow users to focus on their application functions while benefiting from standardized, secure, and ready-to-use services.

IMA: The technology behind KOSMOS

• Historically, in the aeronautical industry, each critical function (equipment control, communication with the ground, etc.) was handled by an independent computer (processor). This was expensive, made aircraft heavier, and complicated interconnections.

• With the increasing computing power of processors, a new paradigm has emerged: Integrated Modular Avionics (IMA). This solution has been implemented on Airbus and Boeing aircraft since the A380 and the B777.
• The solution consists of enabling multiple functions to coexist on the same computer, ensuring that the functions do not interfere with each other.

A key concept: TSP

Time and Space Partitioning (TSP) is based on the following principles:

• Each software application is called a "partition" and has its own memory space and allocated time slots on the processor.
• This separation of resources allows each application to be developed and qualified independently.

• … And this is true even on a processor with multiple cores.

A key tool: the hypervisor

• In the same way as Windows or Linux on a computer, the role of the hypervisor is to allow the execution of each application (partition), while strictly respecting the constraints of the IMA and the TSP.

What is KOSMOS?

• A set of basic building blocks compatible with IMA & TSP, qualified at high criticality levels (ECSS level B):
  • IOS: software partition for managing shared input/output devices (how to communicate with a scientific instrument, a camera, for example)
  • MMDL: software partition for managing memory (storage in particular) to which the processor has access.
  • HSEM: software partition for managing anomalies that may occur somewhere in the Flight Software.
  • CCSW: software partition managing command and control, i.e., communication between the Flight Software and the spacecraft operators on the ground.
    • In particular, a generic library implementing the PUS ground-to-ground communication protocol: libPUS. This library provides a number of basic command and telemetry functions that the satellite can reuse to perform basic operations (sending health-related telemetry, event reports, and monitoring data; updating onboard parameters and data in the satellite's memory, etc.).
  • AUTHSW: Software partition for authentication and encryption of remote controls received by the satellite.
  • OBCPSW: Software partition implementing On-Board Control Procedures, acting as a mini control center onboard the satellite.
• Development kits to help users get started more easily:
  • LVROOT: a sample KOSMOS-based software, which can be adapted and enhanced for their mission.
  • APPDK: a sample software partition, allowing users to develop an application algorithm for their mission without having to worry about the rest of the flight software.
  • APPDKPUS: a software partition similar to APPDK, integrating the PUS library.
  • CCDK: a development kit for the Command and Control partition, allowing users to adapt it to their mission requirements.
• Specific and reusable software components:
  • Qualified boot software enabling secure startup of the Flight Software on Zynq targets.
  • Spatialized calculation libraries and interface standardization tools (partition exchange format, mathematical calculations, etc.).
• Tools to facilitate software development:
  • DevOps building blocks and libraries (CI/CD, test automation tools, etc.).
  • "Card server" mechanisms enabling remote access to hardware targets.