IO - Aerospace Software Engineering

sylvain.guillet · Octobre 1, 2020, 4:22

Bonjour la communauté,

Pour donner suite à ma présentation auprès de la fédération, je souhaiterais vous présenter plus en détail cette suite d’outils et services logiciels dédiés à l’aérospatiale.

Ce post se concentre essentiellement sur le premier module qui consiste à mettre à disposition des acteurs du new space une solution logicielle en astrodynamique sous la forme d’un SDK et d’une API SAAS (Software as a service)

Constat
Les applicatifs actuels du marché sont répartis en deux catégories, les solutions libres d’utilisation comme Spice et les solutions commerciales comme AGI offrant des fonctionnalités qui vont au-delà de l’astrodynamique.
Dans les deux cas ces applications fournissent un service de qualité aux principaux acteurs de l’aérospatiale.
Malheureusement, ces services ne sont pas toujours adaptés aux startups émergentes du secteur.
En effet, elles ne peuvent pas investir le temps nécessaire à la prise en main ou à l’intégration d’outil comme Spice et bien souvent elles n’ont simplement pas les moyens d’investir dans des licences logicielles couteuses.

Face à ce constat, je propose de mettre à disposition des nouveaux acteurs du spatiale européen, une suite d’outils logiciels et de services adaptées à leur planning serré et à leur budget limité.

Objectif et valeurs
Ce projet n’a pas pour but de révolutionner les applicatifs en astrodynamique mais d’en faciliter l’accès.
Par exemple l’intégration numérique fournit pas Spice est robuste, précise et performante, ce serait un excellent point de départ pour le développement de cette solution.
Cette solution se doit d’être cross-plateform et moderne pour s’intégrer facilement avec les technologies actuelles.
Cette suite logicielle serait mise à disposition sous deux formats :

Un SDK afin que la société puisse intégrer la solution dans ses propres applications et bénéficier d’un mode d’exécution autonome.
Une API, permettant à l’utilisateur de consommer l’applicatif en tant que service, ce qui permettrait de distribuer les calculs, mutualiser les couts et offrir une interopérabilité de haut niveau.

Cette solution serait développée autour de 3 axes :

Qualité : Aucun compromis ne serait fait sur cet axe, la qualité des calculs doit être élevée et la totalité du code source devra être couverte par des tests automatisés.
Simplicité : N’importe quel acteur doit être capable de prendre en main ou d’intégrer cet outil à ses applicatifs en quelques heures, cela passe par une conception détaillée du système et la mise en œuvre des bonnes pratiques et standards du génie logiciel.
Accompagnement : « Vous n’êtes pas seul ! » Notre communauté se doit d’apporter un support humain pour accompagner l’utilisateur dans l’intégration de ces outils.

Fonctionnalités
Voici une liste non exhaustive des fonctionnalités qui seraient fournies en première intention :

Définir une orbite basée sur des observations.
Déterminer la taille apparente d’un objet.
Anticiper une occultation.
Calculer les vecteurs vitesse et position dans un référentiel inertiel.
Définir les fenêtres de temps durant laquelle une contrainte numérique est satisfaite. (Ex. Occultation, Transite, Survol, …)
Déterminer l’incidence du soleil, la phase, l’angle d’émission vers un observateur.
Définir les points de survol d’un corps.
Outils de manipulation de matrices.
Opérations sur les référentiels inertielles et non inertielles, ITRS, ICRS.
Correction d’aberration paramétrable.
…

Jalons
La réalisation de ces outils et services serait réalisée en 3 phases.

La première phase concernerait le développement du SDK.
La seconde phase concernerait le développement du système d’information avec l’intégration d’un serveur d’identité et le développement de l’API.
La troisième phase concernerait le développement d’IHM offrant à l’utilisateur une représentation graphique des problèmes résolus par l’API.

Délais
Les technologies et méthodes de développement modernes nous permettraient de réaliser les deux premières phases en moins d’un an, c’est pas une blague

Comment

Une gestion de projet agile basée sur des sprints (itérations) de 15 jours, assurant une livraison à l’issue de chaque sprint.
Un environnement de génie logiciel permettant d’industrialiser les développements et de piloter toutes les phases du projet.
Une chaine d’intégration et de déploiement continu.
Un langage de programmation moderne et cross-plateform.
Une phase de conception détaillée.
Des tests automatisés.

Le long terme
Cette solution serait la première brique d’un système qui ne demande qu’à s’étendre.
Cette croissance pourrait être horizontale, pourquoi ne pas développer un module pour le vol atmosphérique ?
Elle pourrait également être verticale avec le développement d’un portail de gestion des missions.
L’architecture du système devra être pensée pour offrir une modularité et une capacité d’extension importante.

Ressources matérielles et logicielles
Pour que ce projet voit le jour nous aurons besoin de ressources matérielles et logicielles certaines seront libres et gratuites, d’autres feront l’objet d’investissement.
A l’heure actuelle, le principal investissement serait matériel pour héberger notre solution durant sa phase de développement.
Cependant peut-être qu’un partenaire pourrait nous faire une petite place sur ses serveurs pour héberger nos services ?

Ressources Humaines
Pour que ce projet voit le jour nous aurons besoin de compétences hétérogènes.

Tu as des compétences en astrodynamique ou en orbitographie alors tu pourrais peut-être nous accompagner dans l’expression du besoin et le développement du système ?

Tu as le contact facile, alors pourquoi ne pas entrer en relation avec les différents acteurs pour promouvoir et partager nos idées ?

Tu n’as pas de compétences techniques mais une bonne qualité rédactionnelle alors pourquoi ne pas prendre part à l’élaboration de la documentation ?

Tu as des compétences en développement logiciels mais toutes ces équations te donnent le tournis, pas d’inquiétude nous allons te donner les armes pour démystifier tout ça !

Au-delà des compétences techniques, nous souhaitons construire une équipe autour de qualités humaines comme la curiosité, le partage, la bienveillance mais aussi la créativité, la motivation et la Gnaque !

Et maintenant ?
Aujourd’hui tout reste à faire et la première chose c’est de construire une équipe alors n’hésites pas à embarquer sur le projet, le train pour le new space va partir

En attendant, je reste disponible et impatient de pouvoir échanger avec vous !

Sylvain

damien.hartmann · Octobre 1, 2020, 7:44

Hello Sylvain,
Le logiciel SPICE que tu évoques est bien celui de la NASA ?

Peux-tu donner un peu plus de détails sur la cible utilisateurs de cette suite logicielle ? J’imagine que les porteurs de projets open source orbitaux en font partie, je suis curieux du nombre d’utilisateurs / d’organisations cibles dont on parle aujourd’hui, et peut-etre quelques exemples. Je comprends aussi que le fait de rendre ces outils disponibles contribuera à élargir le pool des utilisateurs potentiels.

Je comprends aussi que la partie SaaS implique une idée de business model derrière : les outils eux-mêmes seraient open source, mais tu envisages potentiellement de monter une boîte pour assurer des services d’intégration, d’hébergement et de support ?

En tout cas l’approche présentée apparaît bien réfléchie et bien construite

That’s the Federation spirit

sylvain.guillet · Octobre 2, 2020, 1:00

Hello Damien,

Je vais essayer d’apporter une partie des réponses à tes questions.

Effectivement c’est bien celui-ci, une nouvelle version est attendue pour le mois de novembre et pourrait offrir de belles évolutions en terme d’intégration et de fonctionnalités.

La cible première reste les nouveaux acteurs du spatial qui n’ont pas toujours les moyens humains, financiers ou temporels d’intégrer les solutions du marché parfois onéreuses, complexes à maitriser ou encore surdimensionnées pour le besoin. Pourtant beaucoup de projets devront un jour ou l’autre répondre à la question : « Quelle orbite ou trajectoire permettra de satisfaire mes contraintes. »
Le but étant d’offrir des fonctionnalités de haut niveau, le plus simplement possible pour une intégration efficace dans l’écosystème de l’entreprise.

Les mastodontes du secteur ne sont pour l’instant pas une cible car ils ont déjà les outils nécessaires à leurs missions. Le but ici est simplement de collaborer avec les acteurs du new space et le plaisir d’apporter sa pierre à l’édifice.

Je n’ai pas de chiffre précis concernant le nombre d’utilisateur mais je vois déjà au sein de la Fédération des projets qui seront tôt ou tard confrontés à des problématiques d’astrodynamique.

Comme je l’ai dis précédemment, le but premier est d’apporter sa pierre à l’édifice en prenant du plaisir à le faire. Nous ferons vivre cette solution de manière bénévole grâce à la communauté et aux partenaires d’autant que l’investissement financier est minime.
Cependant si la demande et la charge devaient croitre alors oui, il faudra effectivement se structurer pour respecter nos valeurs.

Merci pour ce retour positif, effectivement ca fait quelques années que j’y réfléchis, j’ai eu l’occasion de réaliser un POC pour mesurer la faisabilité. Aujourd’hui cette fédération se présente comme une réelle chance de pouvoir concrétiser cette idée

stck_lzm · Octobre 2, 2020, 5:27

Moi, je pense la question elle est vite répondu :
http://www.edu.upmc.fr/sdi/berthaud_la201/PDFs/Poly-Meca-solides.pdf

tiphainekle · Octobre 8, 2020, 6:34

@stck_lzm, Ça me rend nostalgique…
Je pense que dans les projets Dryade et Space Servicer, nous aurons besoin d’un tel outils pour définir les paramètres de nos missions plus efficacement.

Ayant déjà utilisé le logiciel STK d’AGI, je me demandais si ton projet auraitles même fonctionnalités, @sylvain.guillet ?

sylvain.guillet · Octobre 8, 2020, 7:25

@tiphainekle On peut voir notre projet un peu comme une version allégée en fonctionnalité de STK, voici quelques fonctionnalités qui seront intégrées dans un premier temps :
• Manipulation des référentiels de temps (TDB, UTC, Sonde, …).
• Manipulation des référentiels de type inertiel et non inertiel.
• Obtenir la position et l’orientation des corps, satellites, instruments, …
• Calculs de coordonnées basés sur une surface modélisée.
• Obtenir des points de survol.
• Définir les angles d’illuminations.
• Définir une orbite à partir d’observations.
• Obtenir une fenêtre satisfaisant des contraintes.
• Vérifier un champ d’observation et anticiper une occultation ou un transit.
• Conversion de coordonnées équatoriales, rectangulaires, sphériques, …
• Manipulation de matrices.
• Intégration des aberrations.
• Propagation d’orbite.
• Manœuvres orbitales.
• Visualisation CGI

Ce système va également être pensé dès sa conception pour pouvoir être embarqué et fournir un service d’orbitographie en cas de perte de liaison avec le sol. Ca pourrait par exemple être l’un des services rendu par la plateforme @project-phoenix-infrastructure-informatique-orbi sur le segment espace-espace.

erwan.zamora · Octobre 9, 2020, 6:36

on a déjà cela

cela aussi

le reste est à venir …

sylvain.guillet · Octobre 9, 2020, 7:05

Bonsoir Erwan,

Tu fais bien d’aborder ce point, on ne voudrait pas faire doublon avec un projet existant, bien que notre projet va au-delà des quelques fonctionnalités citées à titre d’exemples précédemment. Nous allons par exemple industrialiser ce process, offrir une solution multi-plateforme (Embarqué, Intégration à un système d’information,…) mais aussi apporter un support dédié à ces problématiques.

Pour être certains de bien comprendre, quand tu dis :

Tu parles de quel projet ?

Comment s’appelle le logiciel que vous utilisez ?

Quand tu évoques le « reste à venir », est-ce que ça sous-entend que vous avez déjà une équipe de développement en charge de cette partie là ?

erwan.zamora · Octobre 10, 2020, 4:13

Ce n’est pas un problème, je pense, même mieux.

Nous aussi, au moins une partie.

Nous n’avons pas une équipe de développement encore (pas les moyens) mais des bénévoles, dont je fais partie, qui travaillent dessus.

Nous le créons en utilisant des lois physiques, c’est le but à long terme.

AdAstra

damien.hartmann · Octobre 10, 2020, 4:58

Je vais compléter les éléments d’Erwan, sous son contrôle : l’équipe Ad Astra travaille sur un simulateur nommé « meca_vol », qui est destiné à dimensionner le lanceur.
Erwan, est-ce que tu peux pointer vers une présentation plus étendue de meca_vol et de ses fonctions ? Vous avez des specs un peu détaillées à partager ?

sylvain.guillet · Octobre 10, 2020, 5:02

Merci Erwan pour ces précisions, je comprends mieux le contexte.
Est-ce que vous ne seriez pas intéressés de déléguer une partie en vous appuyant sur nos librairies logicielles, vous pourriez ainsi, vous concentrez sur l’intégration de ces composants ou une autre partie du projet sans avoir à vous préoccuper de la qualité des calculs(rapports de tests livrés systématiquement), de la performance, de la maintenance du logiciel ou de sa chaine d’intégration et de déploiement continu. Vous pouvez nous faire confiance, nous sommes tous des professionnels du développement logiciel et vous pourrez évidemment compter sur notre support!
En ce moment nous réalisons le cahier des charges, pourquoi ne pas nous transmettre votre architecture cible ainsi que vos besoins, nous pourrions ainsi l’inclure dès sa conception pour les besoins d’AdAstra. Pour le moment nous estimons le développement de la partie SDK à 3 mois.
Nous pourrions, si vous le souhaitez, vous donner dans les prochains jours une liste précise des services rendus par le SDK ?

erwan.zamora · Octobre 10, 2020, 5:15

c’est exactement cela. Je n’ai rien sous la main actuellement, ou alors dans des vieilles diapos. Je regarderais cela plus tard.

Le logiciel que vous allez faire possèdera-t-il une documentation ouverte? Sera-t-il modifiable par la communauté ?
D’expérience, tous les logiciels opensource de ce type possède une version Community et une version Enterprise. Cela sera-t-il le cas?
Quelles sont les hypothèses physiques prises? Combien de degrés de liberté possèdera le solveur physique de trajectoire ?

C’est ce qui m’importe le plus.

Sera-t-il un logiciel dimensionnant ? Quelles contraintes opérationnelles prendra-t-il en compte ? Sous quelle forme?

sylvain.guillet · Octobre 11, 2020, 1:06

Il serait effectivement intéressant que tu puisses nous faire une présentation du cahier des charges de meca_vol si tu penses que notre projet peut vous aider sur AdAstra. Cela nous permettrait de répondre précisément à tes questions et nous pourrions vous donner une vision claire des besoins d’AdAstra qui seraient couverts par notre projet.

erwan.zamora · Octobre 11, 2020, 4:55

Je pensais plutôt a l’inverse étant donné qu’on a déjà un code mais pourquoi pas ?

sylvain.guillet · Octobre 12, 2020, 8:09

Après en avoir discuté avec l’équipe, il nous semble important de redonner un peu de contexte à notre démarche et de clarifier un point. A ce jour ce n’est pas une finalité pour nous d’intégrer le projet AdAstra au travers de nos outils et services même si nous en serions ravis. Nous sommes dans une démarche communautaire avec une approche globale, il faut simplement voir notre proposition comme une main tendue. Si vous souhaitez la saisir nous pouvons organiser une visio en mp sinon c’est sans rancune que nous poursuivrons notre aventure

erwan.zamora · Octobre 13, 2020, 1:47

Il ne me semblait pas que la discussion tournait autour l’intégralité de votre projet à AdAstra ou inversement. Ici, le but des réponses que j’apportais tournait bien autour de discussions, je précise bien bilatérale, sur des possibles améliorations des cahier des charges respectifs, dans les deux sens.
Nous sommes dans une démarche ouverte avec une approche plutôt singulière, étant donné le domaine. De ce fait, nous ne sommes évidemment pas fermés au partage éventuel de notre retour d’expérience sur le sujet, en toute humilité.

victor · Octobre 20, 2020, 9:19

Bonjour,
On a fait un point d’avancement hier sur le projet Space Servicer. On serait très intéressés par le SDK
Dans un premier temps on pense faire nos calculs à la mains alors si le SDK arrive dans quelques mois ce serait parfait
@sylvain.guillet est-ce que ça te dirait de faire une visio avec notre équipe un de ces jours pour en parler ?

sylvain.guillet · Octobre 21, 2020, 6:21

Bonjour Victor, avec plaisir. Je te propose de planifier une visio en mp.

jlabroquere · Octobre 29, 2020, 6:51

Bonjour,

C’est très intéressant.
Qu’elle serait l’avantage du SDK comparée à une librairie de type Orekit ?

Vous visez quel language ? C++ pour être compatible après avec du Python, Java, etc ?

Jérémie

sylvain.guillet · Octobre 30, 2020, 11:59

Bonjour Jérémie,
Tout d’abord bienvenue dans la fédération
Pour répondre à tes questions, sur un plan fonctionnel c’est sensiblement équivalent.
La différence réside dans l’architecture du système, la performance et la cible utilisateurs.
Le développement d’Orekit a débuté en 2002 par une société nommée CS group, ce SDK a été conçu dans une démarche commerciale pour pouvoir répondre à des appels d’offres internationaux et donc à des utilisateurs experts. CS group a fait le choix de technologies comme java qui pouvaient être pertinentes en 2002 pour une raison d’interopérabilité mais la contrepartie est un impact négatif sur la performance ou encore la portabilité vers un système embarqué. Nous allons dès le départ concevoir une solution qui offre la meilleure performance possible et qui puisse être embarquée, cela passe effectivement par des technologies comme le c++, …
Notre solution se doit également d’être accessible à des utilisateurs non experts mais attention ça ne veut pas dire que la qualité des résultats sera moins bonne, cela passera essentiellement par l’intégration d’automatismes, une architecture logicielle et une ergonomie adaptée.