Définition du profil de mission du démonstrateur orbital Phoenix

Projets PHOENIX - infrastructure informatique orbitale
1

Je viens de finaliser une formation sur le design de systèmes spatiaux et je suis actuellement en stage sur l’analyse de mission et radiatif des cubesats 1U, 2U, 3U et plus.

Avant toute chose il faut pouvoir définir une mission (mission statement) ce qui permet d’entrevoir les besoins de la mission de façon macro et fonctionnels.

Nous ne pouvons pas répondre aux questions suivantes sans avoir un objectif de mission, car celui-ci va conditionner l’ensemble du système.

Les lois spatiales conditionnent la partie orbitale et permettent d’avoir un cadre par exemple les lois sur la durée de vie en orbites sont différent en LEO, ou en GEO ainsi que le retrait de service.

L’orbite en fonction de l’objectif de la mission va condition les différents dimensionnements du système est des sous-systèmes.

Exemple l’exposition aux radiations dépend de l’orbite choisie ainsi que de la date de lancement ou il faut prendre en compte les éruptions solaires à leur maximum qui en LEO.

Pour dimensionner l’EPS il faut encore une fois l’orbite, l’inclinaison, les différentes éclipses durant la mission et la consommation des sous-systèmes, le type de panneaux solaire, etc.

Donc tout part de l’orbite choisie en fonction de la mission/Payload, dans un premier temps il faut sélectionner l’orbite.

Il faut trouver l’orbite de design qui sera l’orbite de référence sur le projet.

Pour la trouver sommes-nous en LEO ou pas ? ( en fonction de la mission)
Si oui l’orbite max sera soumise à la loi spatiale sur la gestion des débris en LEO avec une durée de vie max de 25 ans.

Il faut aussi vérifier le nombre de points de contact avec la ou les stations sol choisi donc il faut testé l’orbite max avec toutes les inclinaisons afin de trouver celle qui maximise les points de passages aux stations sols choisis en respectant une durée de vie de 25 ans max.

Pour l’orbite minimum, basée sur l’orbite max il faut descendre au plus proche en vérifiant que nous respectons les temps de communications nécessaires pire cas avec les stations sols en fonction de l’objectif, durée de la mission.

Ensuite, en déduire l’orbite de design entre l’orbite max et min.

Concernant la taille encore une fois elle dépend de la mission s’il y a un pointage on partira sur du 3U minimum pour intégré un système de contrôle d’orbite et d’attitude pour effectuer les pointages précis soit en direction des stations sols, soit en direction d’autre satellite ou encore pointer le soleil pour recharger les batteries. (NB peut être qu’il est possible de le faire avec un 2U mais 1U pas de place c’est sur)

Concernant les radiations comme dit plus haut cela dépend de l’orbite il y a différent type d’exposition qui n’ont pas le même effect sur les composants.

Le premier point qu’il faut clarifier c’est objectif de la mission/durée/prérequis le reste découlera de cela.

1 « J'aime »
2

J’ai déplacé ton message dans un nouveau sujet, puisqu’il bifurquait pas mal du thread initial.
Je propose qu’on en discute de vive voix lors de la réunion de demain soir 21h, justement dédiée au démonstrateur orbital. On a effectivement évoqué le fait de rentrer dans le détail du profil de mission, et il y a de nombreux trade-offs à faire. Qu’est-ce qui manque dans les objectifs de mission décrits sur la page vitrine par rapport aux objectifs de mission que tu demandes ?

Tu as un modèle à proposer pour la formalisation et le suivi de tous ces trade-offs, issu de ta formation ou autre ?

3

J’ai relu on comprend bien l’objectif mise à part de décentralisé je ne suis pas sur d’avoir compris.

Je pense qu’il manque une durée de mission et qu’allons-nous faire pour le démonstrateur. Dans le planning je n’ai pas compris pourquoi l’analyse mission n’est pas la première tâche et je ne crois pas avoir vu de phase de test non plus alors que c’est une partie critique.

Étape 1 Analyse mission

La mission

  • Quelle est la mission et ses contraintes( durée, station sol, com, loi spatiale, etc…)
  • Choix du type de cube sat en fonction de la mission ou du démonstrateur

L’orbite de design

  • Valider l’orbite de design ( trouver l’orbite max et min, temps au soleil, temps éclipse et bilan radiatif global sur l’orbite choisie)

Pour commencer.

Après on peut entrer dans le détail technique ( mode du sat, dimensionnement du système électrique) mais avant ça n’a pas de sens.

Tout part de la mission si on parle de démonstrateur qu’allons-nous démontrer ? Combien de temps ?

La reu de 21:00 cela fait tard pour moi je vais essayer quand même.

4

Tu fais référence à " architecture décentralisée et modulaire" ? Cela signifie que c’est une architecture qui ne dépend pas d’un point central (une analogie serait de la distribution de vidéo en streaming centralisée - tout part d’un serveur/opérateur unique, s’il tombe, plus personne n’a accès au service - vs de la distribution vidéo streaming en peer-to-peer - si un des acteurs du réseau de distribution tombe, d’autres prennent le relais).

Comment procéder pour définir la durée de la mission ?
Quant à ce que nous allons faire pour le démonstrateur, peux-tu être plus spécifique, donner des exemples ?

Est-ce que tu peux préparer un modèle de document à compléter dans le NextCloud du projet ? En y mettant déjà les éléments issus des pages vitrines du projet et de ses sous-projets.
Merci pour ton implication !

5

Salut Samy,
Je serais ravis de travailler avec toi sur le design de mission pour le démonstrateur.
Je pense qu’il faut qu’on se retrouve autour de la table lors des réunions du mercredi, nous avons eus plusieurs discussions pour lancer un travail de définition du profil de mission pour Phoenix et pour le démonstrateur N°1. Tu évoques la latence à juste titre pour le choix de l’orbite, il y a par exemple aussi la capacité de calcul qui est potentiellement contraignante sur le système. Il y peut-être d’autres paramètres.
J’avais trouvé un template d’Open Source Satellite mais peut être a tu des idées de template pour un bon design de mission ?
Damien a créée un Gitlab pour se créer des taches à les faire avancer, dans le sous projet lié au démonstrateur : https://code.federation-openspacemakers.com/p/P0092/d-monstrateur-orbital/-/issues/1

6

Concernant la mission @samy.tahar.berrabah, et au vu de ce que l’on a écrit dans les objectifs, je retiens principalement la démonstration suivante :

  1. communication avec un satellite tiers :artificial_satellite: (oui j’aime ce cas d’usage :wink: )
  2. exécution d’un code non embarqué au décollage mais reçu en orbite via une station-sol :arrow_up: :satellite:(potentiellement tierce aussi).
  3. renvoi du résultats à une station-sol :arrow_down: :satellite:.

NB : J’ai donc éliminé la communication intra-phoenix dans cette démonstration car on se focalise sur un unique satellite dans un premier temps. :satellite::arrow_left::arrow_right::satellite:

Pour arriver à cette démonstration, le plus « simple » est probablement de viser en fait 2 satellites tiers :artificial_satellite: :artificial_satellite: et 2 code différents pour véritablement démontrer la versatilité du satellite Phoenix.

Une façon de définir l’orbite du satellite Phoenix serait donc d’avoir 2 satellites candidats à la communication et le code à exécuter pour chacun d’eux si, et seulement si, il existe aussi une orbite Phoenix permettant d’établir ces 2 liaisons. Dés lors, on pourra alors calculer le temps soleil & compagnie.

C’est une première approche…
Bien sûr, on peut aussi choisir de prioriser sur l’exécution de code à distance, dans ce cas, une orbite passant par un maximum de station-sol « amies » serait le premier critère de choix.
NB : j’entends par « amies » celles qui nous permettraient facilement d’uploader du code à exécuter.

On pourrait aussi imaginer des trucs un peu hybride montrant que l’on peut exécuter du code et émetre des données spécifiques en fonction du positionnement. Par exemple, un satellite capable d’ émetre du code morse facilement écoutable depuis la terre et dont le contenu proviendrait du code exécuté. Par exemple, on pourrait écrire un programme disant « bonjour » aux habitants du pays survolés. :clown_face: . La fois suivante on change de programme et on envoie le nombre d’heure de vol ou que sais-je…

Pour revenir au premier cas d’usage, on pourrait faire un satellite « convertisseur ». Il pourrait recevoir les informations d’un satellite tiers et les retransmettre dans un autre format. Par exemple, s’il passe sous un satellite de type NOAA, il renvoie les informations dans un autre format. Et à l’inverse, s’il passe sous un satellite géostationnaire genre EUMETSAT (Méteosat), il émet au format des NOAA.

1 « J'aime »
7

Puisque je suis parti à brainstormer, et vu le document d’OpenSourceSatellite sur IoT ConOps Satellite, on pourrait aussi faire simplement cela mais avec un pré-traitement spécifique exécuté à bord du satellite Phoenix.
Je veux dire écouter tout un tas d’IoT terrestre, executé un programme de traitement spécifique à la demande et émettre le résultat à une station sol déterminée elle aussi par programme…

Une autre chose à tester aussi serait bêtement une Software Defined Radio (SDR) low-cost et donc faire un satellite transpondeur reprogrammable…

8

Hello Benjamin,

Avec plaisir je vais faire le max pour être la à la prochaine réunion.

9

Hello Loic,

Dans ce cas, les satellites ont été dimensionné pour une mission spécifique, il me semble compliqué de changer un programme de mission pour lancer des communications cependant dans le cas ou la mission du satellite est terminé et qu’il est toujours en orbite il y aurait peut être quelque chose a faire.

10

Le doc est intéressant je n’ai pas encore tout lu.

En 6.1 Orbite

The CubeSat IoT constellations (e.g. Lacuna Space, Fleet Space, Kepler, etc.) have
their spacecraft in sun-synchronous orbits of around 500 - 600 km altitude [4] [5]
[6]. This orbit choice is likely driven by both the availability of launch vehicles and
the benefits of a sun-synchronous orbit which can provide global coverage due to
the precession of such an orbit. The low altitude is also beneficial for the payload
operation as the received power in the payload receiver would be higher, reducing
the required sensitivity of the payload.

Ils sont raison maintenant je ne pense pas qu’il faille se limiter à une SSO même si c’est le plus probable car étant donnée que nous sommes passagé secondaire nous dépendrons de la charge principale.

Cela ne veut pas dire que cela sera notre meilleur orbite pour la mission donner je parle plus d’inclinaison à voir cela depand de l’objectif de communication en latence et en contact aux stations sol.

11

@samy.tahar.berrabah Pour être plus clair, la mission du satellite Phoenix est de pouvoir exécuter du code uploadable et de pouvoir communiquer de manière flexible avec d’autres satellites. Autrement dit, cela fait partie du payload du satellite Phoenix.

Et si tu parlais de modifier la mission de satellites tiers existant, alors ce n’est pas non plus ce que j’ai voulu exprimer. Si le satellite Phoenix passe dans la zone d’émission radio d’un satellite NOAA (pour simplifier l’exemple), alors le satellite Phoenix peut toujours écouter celui-ci sans modifier la mission du NOAA. Le code a exécuter (et modifiable) dont je parlais est exécuter comme payload sur le satellite Phoenix.

Suis-je plus clair ?

12

Hello, merci pour ton message.
C’est moi qui risque de ne pas être là demain soir mais on va y arriver :slight_smile:

13

Suite aux discussions de ce soir, j’ai commencé à décrire la mission du cubesat démonstrateur dans un document.
Je commencerai le modèle Capella sous peu pour mieux préciser celui-ci et avoir des schémas à ajouter un peu propre…

1 « J'aime »
14

Question:
vous souhaitez le lancer quand votre CubeSat ?

15

Quand il sera prêt :slight_smile:
On vise le 3e trimestre 2023, voir sur la page vitrine du sous-projet dédié.

16

Si vous n’allez pas trop « haut » Ad-Astra sera peut-être prête… :smirk:

2 « J'aime »
17

Pour votre démonstrateur, il y a peut-être une opportunité à saisir:


18

Merci pour le partage Frédéric, nous avions bien vu. Mais avec le soutien du CNES pour le projet PHOENIX, nous sommes confiant sur le faire d’obtenir un créneau pour un 2U ou 3U en 2023. Le vrai challenge, c’est de concevoir et fabriquer quelque chose qui mérite d’être envoyé :wink:
D’où les multiples échanges sur le sujet.

19

Ok, ça marche. C’est vrai que c’est du boulot pour mettre au point quelque chose comme ça même si c’est un démonstrateur. J’ai hâte de voir le résultat et je croise les doigts :crossed_fingers: pour 2023 :artificial_satellite: :rocket:

20

Peut-être des idées dans cette vidéo https://youtu.be/dA85zot-Dl4 pour affiner les premières démonstration…

1 « J'aime »