À l’aube de la course à l’espace, lorsque les ordinateurs occupaient des pièces entières, les satellites et les sondes devaient s’appuyer sur l’électronique analogique pour lire à partir de leurs différents capteurs et transmettre les données résultantes au sol. Mais il ne fallut pas longtemps avant que les ambitions spatiales de l’humanité ne dépassent ces premiers systèmes, ce qui a conduit à de vastes progrès dans les ordinateurs numériques spatiaux à l’appui des programmes Gemini et Apollo de la NASA. Aujourd’hui, la construction d’un vaisseau spatial sans ordinateur de bord (ou même plusieurs ordinateurs redondants) est inconnue. Même le plus petit des CubeSats exécute probablement Linux sur un système multicœur.
En tant que tel, le développement de logiciels fait désormais partie intégrante de la conception des engins spatiaux – du code de bas niveau responsable du déclenchement des systèmes d’urgence aux interfaces graphiques tactiles 3D utilisées par l’équipage pour naviguer dans l’engin. Mais comme vous vous en doutez, les enjeux ici sont plus élevés que n’importe quelle tâche de programmation normale. Si votre code se bloque ici sur Terre, c’est une nuisance. S’il se verrouille sur un atterrisseur lunaire quelques secondes avant qu’il ne touche la surface, cela pourrait être la fin de la mission.
Pour mieux comprendre ce coin fascinant du développement logiciel, nous avons invité Jacob Killelea à animer la semaine dernière
Logiciel pour Satellites Hack Chat. Jacob est un ingénieur avec une formation en aéro et thermodynamique, en systèmes de contrôle et en survie. Il a écrit du code pour des engins spatiaux destinés à la Lune, et peut-être le plus important, est un lecteur avide de Hackaday.
La fiabilité avant tout
La conversation a commencé comme on pouvait s’y attendre, plusieurs personnes souhaitant savoir quels types de langages, de frameworks et même de systèmes d’exploitation sont utilisés dans les engins spatiaux d’aujourd’hui. Jacob dit que même s’il existe une quantité incroyable de variabilité en fonction du matériel et de ce que le logiciel doit faire, une grande partie est familière à des gens comme nous. Il dit que le langage de choix a tendance à être C, et que même si Linux est utilisé, il a tendance à être pour des tâches de niveau supérieur qui n’ont pas besoin de se produire en temps réel. S’il ne s’exécute pas sur le métal nu, le code critique est susceptible de s’exécuter sur quelque chose comme VxWorks. Bien que même ici, il avertisse que la communauté aérospatiale préfère s’en tenir à ce qui fonctionne, vous pouvez donc trouver que le vaisseau spatial pour lequel vous avez été chargé d’écrire du code utilise un système d’exploitation du début des années 2000.
La fiabilité est finalement le nom du jeu lors de l’écriture de code pour les applications spatiales, ce qui a amené la conversation vers la tolérance aux pannes et le fonctionnement dit en « mode sans échec ». Étant donné que les défauts peuvent être déclenchés par des événements externes hors de votre contrôle (tels que les rayons cosmiques), même le code le plus soigneusement conçu et testé peut un jour planter. Dans ce cas, il doit y avoir un système secondaire qui peut prendre le relais et mettre l’engin dans un état connu de bon fonctionnement. Fait intéressant, ces « contrôleurs en mode sans échec » sont souvent un module dédié et pas seulement un mode de fonctionnement différent de l’ordinateur principal.
Cela fournit une véritable redondance en cas de panne complète de l’ordinateur, mais n’est pas sans risque – Jacob a rappelé une mission qu’il avait étudiée où un contrôleur conçu pour un véhicule précédent avait été réutilisé sur un autre avec une configuration physique différente. Tout allait bien jusqu’à ce que le satellite passe finalement en mode sans échec, moment auquel les tentatives du contrôleur pour stabiliser l’engin l’ont en fait rendu incontrôlable. En fin de compte, le « mode sans échec » a fini par être tout sauf cela, et le véhicule a été perdu.
Testez comme si vous voliez
D’autres personnes dans le chat ont voulu savoir quel type de simulations ou de tests peut être effectué avec un logiciel de vaisseau spatial ici sur le terrain. Jacob dit que l’un des outils les plus puissants est ce qu’on appelle un FlatSat, qui pourrait être considéré comme quelque chose qui s’apparente à la version maquette du matériel final du vaisseau spatial. Tous les composants électroniques de l’engin sont disposés sur un établi, avec de nombreux points de test qui permettent de puiser dans les bus d’alimentation et de communication. Cela donne aux ingénieurs l’accès nécessaire pour tester différents modules et simuler diverses pannes d’une manière qui serait difficile, voire impossible, s’il utilisait une réplique du matériel de vol.
Mais encore, cela ne vous mène que jusqu’à présent. Jacob souligne qu’il est pratiquement impossible de simuler avec précision l’environnement spatial. Il n’y a aucun moyen de créer de la microgravité en laboratoire, alors comment saurez-vous quel est son impact sur vos unités de mesure inertielle (IMU) en orbite ? Comment pouvez-vous être sûr que votre traqueur d’étoiles optique ne sera pas confus lorsque l’engin tourne lorsque votre banc d’essai est boulonné à la table ? La réponse est simplement que vous ne pouvez pas. Tout ce que vous pouvez faire est de tester autant de cas extrêmes que vous pouvez imaginer et de vous assurer que le système peut échouer aussi gracieusement que possible.
Cela dit, vous pouvez avoir une idée de la façon dont vos appareils électroniques réagiront au rayonnement cosmique sans faire de stop dans l’espace. Jacob dit qu’il a été impliqué dans un projet où ils ont testé leur système contre les défauts induits par les radiations en le plaçant dans le cyclotron de la Texas A&M University et en le frappant avec des faisceaux de protons. Cela a produit de nombreuses conditions de panne, dont certaines pour lesquelles ils ont pu mettre en place des procédures de récupération de l’appareil. Bien sûr, il n’y a aucun moyen de prédire ce qui se passera réellement dans l’espace, et les satellites en orbite inférieure sont partiellement protégés des radiations par le champ magnétique terrestre, mais il est toujours bon d’avoir au moins une idée de ce à quoi vous êtes confronté.
Sur les épaules des géants
Au cours des décennies passées, chaque vaisseau spatial ou mission était une entreprise entièrement nouvelle – un véritable genre de chose « là où personne n’est allé auparavant ». Mais les ingénieurs aérospatiaux d’aujourd’hui bénéficient de plateformes spatiales partagées et de cadres logiciels robustes qui leur permettent d’intégrer les leçons durement apprises des missions précédentes dans leur nouveau vaisseau.
Par exemple, Jacob a fortement recommandé à toute personne intéressée par les logiciels d’engins spatiaux de jeter un coup d’œil au Core Flight System (cFS) de la NASA. Ce cadre logiciel de vol sous licence Apache peut fonctionner sur Linux et divers systèmes d’exploitation en temps réel (RTOS), et fournit des modules pour diverses tâches liées aux vols spatiaux telles que la télémétrie, la gestion des processus, les rapports d’erreurs, la planification des commandes, etc. Même si votre homebrew rover n’ira probablement pas beaucoup plus loin que le jardin arrière, il pourrait probablement bénéficier d’une partie de la recherche et du développement de logiciels que la NASA a déjà effectués.
Jacob a également mentionné que les satellites plus modernes, en particulier les variantes plus grandes et plus performantes qui fonctionnent dans l’espace lointain, ont suffisamment de puissance de calcul pour pouvoir offrir des environnements virtualisés pour les «charges utiles logicielles» qui sont téléchargées depuis le sol. Ainsi, par exemple, si vous vouliez mener une sorte de recherche à l’aide des capteurs d’un vaisseau spatial donné, vous pourriez potentiellement télécharger votre propre code qui fonctionnerait dans un environnement protégé où les pannes ne mettront pas en danger les systèmes vitaux du vaisseau.
Ceci est particulièrement utile sur les engins spatiaux conçus pour l’exploration ou les observations scientifiques. Il s’avère que le télescope spatial James Webb (JWST) utilise un système comme celui-ci afin que les scientifiques qui « visitent » virtuellement l’observatoire puissent faire fonctionner ses instruments en toute sécurité grâce à des programmes écrits en JavaScript.
Jacob a eu la bonté de terminer la conversation avec un aperçu des divers systèmes et technologies en jeu dans les engins spatiaux modernes, tels que les bus de données standardisés ou les protocoles de télémétrie. Fondamentalement, il a pris le temps de répondre aux questions que la plupart d’entre nous ne sont pas assez versés pour poser, et les résultats ont été absolument fascinants. Comme on dit, vous ne savez pas ce que vous ne savez pas.
Nous tenons à remercier Jacob d’avoir pris le temps de Jacob pour nous donner un avant-goût de ce que c’est que de développer des logiciels pour les engins spatiaux modernes. Bien que nous n’ayons peut-être pas la chance d’exécuter l’un de nos posséder code en orbite, nous pouvons certainement tous bénéficier de certaines des leçons apprises en opérant dans un environnement aussi hostile.
Le Hack Chat est une session de chat en ligne hebdomadaire animée par des experts de premier plan de tous les coins de l’univers du piratage matériel. C’est un excellent moyen pour les pirates de se connecter de manière amusante et informelle, mais si vous ne pouvez pas le diffuser en direct, ces articles de synthèse ainsi que les transcriptions publiées sur Hackaday.io vous permettent de ne rien manquer.
