Étude de planification embarquée pour essaims satellitaires

L’étude explore la planification autonome, embarquée et coordonnée d’un essaim ou d’une constellation en réseau. Elle doit identifier les fonctions et contraintes pertinentes pour les missions considérées, comparer des méthodes de planification et évaluer leur embarquabilité : calcul, énergie, mémoire, interfaces et réactivité. Les cas d’étude sont construits avec le CNES et peuvent évoluer au fil des analyses.

Phases de l’étude

1. Prospective et sélection. Analyse des besoins mono-satellite puis multi-satellites, constitution d’un panel de cas d’étude de complexité graduelle et recherche bibliographique, principalement sur les missions satellitaires, avec possibilité d’élargissement à l’aéronautique ou à la robotique. L’analyse couvre les architectures et méthodes candidates, la stratégie de développement et de validation, ainsi que les environnements de simulation ; ces choix sont soumis à l’approbation du CNES. Les résultats et choix motivés alimentent le rapport intermédiaire 1.

2. Implémentation et application. Modélisation générique puis appliquée aux cas d’étude ; prototypage simplifié et comparaison des performances des méthodes avant sélection conjointe avec le CNES. Le titulaire réalise ensuite une ou plusieurs maquettes détaillées, en recherchant la réutilisation des briques logicielles, et rédige les spécifications du prototype. Les choix doivent tenir compte des caractéristiques des cartes envisagées — vitesse d’exécution, parallélisation, mémoire vive et de masse —, du système d’exploitation, du langage et des échanges intra- et inter-satellites. Les modèles sont conçus en vue du portage sur cible et de leur validation croisée avec le modèle sur carte. La maquette doit produire et consommer les données d’interface nécessaires ; ses contextes de test et de validation et un manuel utilisateur sont à fournir. Les licences open source dites « contaminantes » sont exclues.

3. Intégration et validation. Prototypage sur une carte d’évaluation, par exemple ZYBO, avec tests et mesures de performance ; plusieurs modèles de cartes peuvent être retenus conjointement avec le CNES. La solution est ensuite évaluée sur un banc ou simulateur représentatif d’un logiciel de vol, fourni par le titulaire ou, si retenu par le CNES, mis à disposition par celui-ci. Dans le cas du banc CNES, le code peut être porté sur carte ou sur un émulateur intégré. Le titulaire fournit les scénarios et leurs contextes, respecte les spécifications d’interface et participe aux tests ; il expose les performances, limites et prérequis de la solution.

Interfaces et banc de validation

Le banc SWARM.NET décrit en annexe peut simuler plusieurs satellites, leurs orbites en temps réel, les transceivers radio des liaisons inter-satellites (ISL) et les récepteurs GNSS ; le logiciel de vol peut s’exécuter sur matériel connecté ou sur émulateur intégré. L’OBSW comprend une mise en œuvre réseau (IwIP, OSPF, PIM). Les modèles ISL décrits distinguent liaison physique, liaison fonctionnelle et gestion réseau par flooding. Ils couvrent notamment le format Proximity-1 (CCSDS 211.0-B-6), des horodatages de ranging à 1 ns et un tampon d’envoi configurable de 100 Kbit par liaison, avec un créneau d’envoi par seconde. Six modes de débit sont indiqués : Q1 100, Q2 75, Q3 50, B1 30, B2 20 et B3 10 kbit/s. Toutefois, depuis la version V6.0, le débit est fixé à Q1 (100 kb/s) : la commutation selon le SNR est spécifiée mais n’est pas activée. Le modèle ne représente pas de tampon de réception et ne gère pas le routage réseau multi-serveurs ; les échanges décrits sont intra-serveur.

Livrables

À fournir : comptes rendus après chaque réunion ; rapports d’étude intermédiaires 1 et 2 et rapport final ; spécification du prototype ; manuel utilisateur ; sources et exécutables de la maquette et du prototype, leurs dépendances et les éléments logiciels développés pour l’analyse et l’évaluation ; contextes, données et scénarios de simulation ; plans de programmation et métriques d’évaluation. Les versions intermédiaires de la maquette sont attendues en phase 2. Les livraisons logicielles comprennent un checksum pour les exécutables, les options de compilation des sources, les tests de validation et un moyen de non-régression. Une fiche de synthèse publiable en anglais, d’une page A4, est également attendue en fin de prestation.