Juste pour mettre par écrit ce que j’ai actuellement dans la tête pour l’architecture globale (hors IT) de PHOENIX, j’ai fait le petit schéma suivant.
C’est peut-être à jeter complètement ou en partie, mais ça donne une première base sur laquelle réfléchir et à challenger.
Notamment : est-ce que les noeuds de traitement communiqueront directement entre eux, ou au travers des noeuds de com ? Est-ce que l’on sépare le réseau inter-noeuds de traitement de celui avec les objets « clients » ?..
Alors je me lance moi aussi pour mettre par écrit des choses qui me viennent dans la tête un peu orientées DTC :
Architecture bord massivement répartie vs spécialisation fonctionnelle de certains nœuds ?
Privilégier la standardisation :
Option 1 : nanosats identiques, dotés des mêmes fonctions, même si elles ne sont pas actives tout le temps (acquisition, calcul, communication entre satellites, communication avec la Terre). Cela donne de la robustesse au système via l’interchangeabilité des rôles de nœuds, permet de la standardisation et de la fabrication en serie.
Option 2 : minimiser le nombre de nœuds spécialisés (nœuds de communication vers la Terre, nœuds de calcul, nœuds stockage).
-> Minimiser le nombre de nœuds nécessaire au fonctionnement du système
-> Standardiser les fonctions nœuds et utiliser une architecture bord répartie
Privilégier des traitements embarqués répartis. La puissance de calcul totale disponible dans la constellation en utilisant des CPU COTS (réduction du NRC et du RC) normalement sera très supérieur à celle d’un calculateur spécialisé développé ad hoc.
S’inspirer des architectures sol de traitement réparti.
-> Privilégier l’utilisation de COTS
-> Minimiser les ressources nécessaires avec des liaisons non permanentes mais possibles à tout moment pour tous les besoins de communication (vers nœuds, vers sol)
Entre nœuds :
Communication omnidirectionnelle pour se passer d’un système de pointage entre les nœuds (possible ?)
-> limiter la consommation du système télécom
Vers le sol
-> Faire le maximum de traitements en embarquée pour limiter les données transférées vers le sol ?
La stratégie de mise à poste, de commande-contrôle et d’autres opérations de routine ont un impact direct sur les ressources nécessaires (système anti collision, Sys propulsion et complexité de la plateforme vs simplicité des opérations sol).
-> Minimiser les opérations de mise à poste vs précision et répartition optimale
- > Minimiser le nombre d’opérations sol : concept auto-opéré (comme un essaim)
Segment sol
Interfaces bord /sol
Architecture Nanosat (nœud)
Etc.
Lors de la réunion de jeudi, on a discuté le fait de créer des visuels du système global pour faciliter la communication, afin de permettre à des nouveaux venus et parties prenantes externes de facilement se rendre compte de ce que ça représente. Le schéma d’architecture Capella est un peu trop hermétique pour cela, est-ce que quelqu’un a des compétences et un outil pour réaliser un schéma propre ?
La version actualisée et plus propre de mon schéma papier tout en haut de ce thread 
Je vous partage ma première version faite avec Inkscape côté outil logiciel et des icônes de TheNounProject de l’autre :
C’est une petite base, je propose de l’ajouter à la page vitrine du projet.
Je n’ai pas séparé de noeuds de communication par rapport aux noeuds de calcul à ce stade, c’est encore un sujet à éclaircir plus loin dans le développement projet.
