Objectifs initiaux (et toujours actifs) de KOSMOS

• Permettre la réutilisation de fonctions récurrentes sur les calculateurs spatiaux sous forme de bibliothèques ou de partitions.
• Simplifier leur intégration et garantir leur indépendance grâce aux garanties de modularité offertes par le TSP/A653.
• Permettre aux utilisateurs de se concentrer sur leurs fonctions applicatives tout en bénéficiant de services standardisés, sécurisés et prêts à l'emploi.

IMA : La technologie à l’origine de KOSMOS

• Historiquement, dans le milieu de l’aéronautique, chaque fonction critique (contrôle d’un équipement, communication avec le sol, etc.) était assurée par un calculateur (processeur) indépendant. Ce qui était cher, alourdissait les avions et complexifiait les interconnexions.

• Avec l’augmentation de la puissance de calcul de processeurs, un nouveau paradigme apparait : l’IMA (Integrated Modular Avionics). Cette solution est mise en œuvre sur les avions Airbus & Boeing depuis l’A380 et le B777.
• La solution consiste à faire coexister plusieurs fonctions un même calculateur en s’assurant que les fonctions ne se marchent pas les unes sur les autres.

Un concept clé : le TSP

Le TSP, pour Time & Space Partitionning, a pour principes :

• Chaque application logicielle est appelée "partition" et dispose de son propre espace mémoire et de ses propres plages horaires allouées sur le processeur.
• Cette séparation des ressources permet de développer et de qualifier chaque application indépendamment.

• Et ce, même sur un processeur comportant plusieurs cœurs.

Un outil clé : l’hyperviseur

• De la même manière que Windows ou Linux sur un ordinateur, le rôle de l’hyperviseur consiste à permettre l’exécution de chaque application (partition), en respectant strictement les contraintes de l’IMA et du TSP.

Qu’est-ce que KOSMOS ?

• Un ensemble de briques de base compatibles IMA & TSP, qualifiées à de hauts niveaux de criticité (niveau B ECSS) :
  • IOS : partition logicielle de gestion des périphériques entrées/sorties partagées (comment communiquer avec un instrument scientifique, une caméra par exemple)
  • MMDL : partition logicielle de gestion de la mémoire (de stockage notamment) à laquelle a accès le processeur.
  • HSEM : partition logicielle de gestion des anomalies pouvant se produire quelque part dans le Logiciel de Vol.
  • CCSW : partition logicielle gérant la commande-contrôle, c’est à dire la communication entre le Logiciel de Vol et les opérateurs de l’engin spatial, au sol.
    • En particulier, une librairie générique implémentant le protocole de communication bord-sol PUS : la libPUS. Cette librairie offre un certain nombre de télécommandes et télémesures de base que le satellite peut réutiliser pour réaliser des fonctions de base (envoi de télémesures de bonne santé, d’évènements, de surveillances ; mise à jour de paramètres à bord, de données en mémoire du satellite, etc.).
• AUTHSW : partition logicielle d’authentification et de chiffrement des Télécommandes reçues par le satellite.
• OBCPSW : partition logicielle implémentant des Procédures Bord jouant le rôle de mini centre de contrôle à bord du satellite.
• Des kits de développements permettant à l’utilisateur de démarrer plus aisément :
  • LVROOT : un logiciel d’exemple basé KOSMOS, à adapter et enrichir pour sa mission.
  • APPDK : partition logicielle exemple, permettant de développer un algorithme applicatif pour sa mission sans avoir à se préoccuper du reste du Logiciel de Vol.
  • APPDKPUS : partition logicielle analogue à APPDK, intégrant la librairie PUS.
  • CCDK : un kit de développement de la partition Commande Contrôle permettant de l’adapter à son besoin mission.
• Des composants logiciels spécifiques et réutilisables :
  • Un logiciel de boot qualifié permettant, sur cible Zynq, de démarrer le Logiciel de Vol en toute sécurité.
  • Des librairies de calcul spatialisées et de standardisation des interfaces (format d’échanges entre partitions, calculs mathématiques, etc.).
• Des outils pour faciliter le développement logiciel :
  • Briques et librairies DevOps (CI/CD, outils d’automatisation des tests, etc.).
  • Mécaniques de « serveur de cartes » permettant l’accès à distance à des cibles matérielles.